Build for branches

Jul 4, 2016 at 7:12 PM
I come from Spanish community and I am trying to understand what are "builds for branches" as in page 11 is said: "It can be helpful to name builds for branches"
I know what a build is (compiling source code, right?) and what a branche is (isolation of source code in TF, right?), but what is a "build for branch"? A branch for a build has more sense to me.
This confusion can be due to my language. So I hope someone can understand and help me. Thanks.
Jul 4, 2016 at 7:50 PM
Your assumption was correct I think, that this is just a language issue. Let me try to help. Keep in mind there can be many different ways to use branches. I will give just one illustration. But you can do things differently.

Assume we have 2 branches:

Assume we have 3 environments:

Assume we have a workflow like this:
Developers work in 2-week sprints. During the sprint, developers check in changes that are being developed into the DEV branch. There is a build for the DEV branch that is triggered on every check-in. It compiles the code and runs unit tests. We name it "Product X DEV CI" to make it obvious to everyone that this build is associated with code in the DEV branch. The "CI" indicates "Continuous Integration" to indicated it is triggered on every check-in. We have a second build on the DEV branch, named "Product X DEV Nightly." Every night at midnight, ththise Build on the DEV branch builds the software on the DEV branch, and releases the results to a Test environment.
Once the Sprint is over, QA staff and customers review the resulting software. If it passes QA and User Acceptance testing, developers merge the code into the MAIN branch, and check it into the MAIN Branch. There is a build for the MAIN branch that triggers automatically. We name it "Product X MAIN Nightly" to clearly indicate this build is for code in the MAIN branch. Every night, a release is automatically generated for whatever is in the MAIN branch, deploying to PreProduction. There, further, more stable testing can occur.

Finally, when all is OK, you can manually trigger a release on the MAIN branch to production. You need a release definition for that, but not necessarily a special build.

Notice in this story that we name the builds on the Dev branch for the branch of code they are building. Example: "Product X DEV CI" or "Product X DEV Nightly." We are naming the build for the branch, just as described in the words you copied from the manual.

You could flip the words around and say you have "one branch for each build." But thatimplies that the build is chosen first, then we make a branch to match it. In contrast,, I would recommend you first design your development workflow, and design branches to support it, and finally, design builds to support CI and your release strategy. Also, as illustrated, we may often have more than one build on a particular branch. But it would be unusual to have more than one branch in a build.

To say "we name branches for builds" is sort of like saying "we name children for their birth certificates." Actually, we name the children first, then we name the birth certificates to match the children. Similarly, we first decide on our branch strategy. Then we name our builds for our branches.
Marked as answer by henryrt on 7/4/2016 at 1:09 PM
Jul 4, 2016 at 7:53 PM
Here is a simpler reply. focused on the grammar.
"It can be helpful to name builds for branches"
could be written like this
"It can be helpful to name builds with names that indicate the branch of code that is the source of the build."
Marked as answer by henryrt on 7/4/2016 at 1:09 PM
Jul 4, 2016 at 8:09 PM
Thank you so much David for taking your time to help me. Your answer is crystal clear to me now.