Help me understand how we can use a Build Server- Jenkins or TeamCity ?

Camillia
Camillia used Ask the Experts™
on
We're a team of 3 developers and we use TFS for our source control.

1. This is how the previous developer moved code to QA and Prod:
     a. He published code locally
     b. He used BeyondCompare to compare the files to the folder on the QA or Prod server
     c. He copied the Bin folder or whatever files changed to QA or Prod servers

We're looking into Build Servers. Someone mentioned Jenkins or

Questions:
1. How does Jenkins or TeamCity work with TFS? We can still use TFS, correct?
2. We have a Dev server, QA server and Prod. Suppose I make a change to my code. Does this change automatically get uploaded to the Dev server when I check into TFS?
3. What if all 3 of us make changes to the project and check in the code. How does the merge happen? do we still need to merge in TFS, check in and then Jenkins/TeamCity takes over of moving code?

4. This is how our TFS branches are setup --> we each have our own branch (3 branches). We check in to our own branch. Then we merge into our DEV branch. We eventually use the DEV branch to publish code for Production.  
  a. If we use a Build Server, how can we ensure the DEV branch is not messed up and has clean code for Prod?
  b. Do we need a "pre-DEV" branch ---> Jenkins/TeamCity builds to "Pre-DEV" and then I'll manaully merge into "DEV" branch and have a solid code base for Prod?

I need to wrap my head around this and I don't quite understand how a Build Server will work with TFS and our current process.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Glanced up at my screen and thought I had coded the Matrix...  Turns out, I just fell asleep on the keyboard.
Most Valuable Expert 2011
Top Expert 2015
Commented:
1) There is source control, and then there is a build machine. Source control, as you probably know, tracks changes to source files. Often you have multiple "branches" of your source, where each branch corresponds to a path of development (e.g. branch per environment, branch per feature, branch per bug, etc). Ideally, you have one branch that is always and forever stable. You can rebuild from that branch and immediately push to production--that code compiles and has (hopefully) been tested.

A build server is a stable, consistent environment for compiling your code. It helps rid your team of "works on my machine" problems. Think about happens when Steve downloads some cool library from some blog (instead of from NuGet), and he forgets to check in that library. What happens when you get the latest changes on your machine?

All that said, how do you know that a branch compiles? You have to pull down the latest changes and compile it. What happens when Steve checks in code that doesn't compile to the stable branch, and then goes on vacation. When do you find out that the code is broken? Well, the next time someone gets the latest changes...or Steve gets back from vacay. That introduces risk to your codebase.

A build server acts like another developer on the team. This team member gets the latest changes as soon as they become available--typically any time a real developer checks in. If the build server can't compile the code, then you get (almost) immediate feedback that there's a problem. Now Steve doesn't go on vacation until he fixes the build. (Hopefully he doesn't walk out the door after triggering a checkin!)

This bit is really more of a continuous integration (CI) thing than a build-server specific thing.

2) That depends on how you set up your CI. In my experience, deployments to Dev aren't automatic. You don't want a developer (or QA staff) to be in the middle of testing some aspect of the system and then the system suddenly stops working or drops the user's session, etc. You can certainly automate the physical deployment of the files, but I would suggest setting up a build that is triggered manually. You want to be sure to coordinate triggers of this build with your team.

3) Typically, as long as two (or more) people aren't working in the same file, then merging is inconsequential. Even if two people are working in the same file, it's only when two people touch the same line of code (or blank line) that merge conflicts happen. Your source control should prompt you for conflict resolution if it arises.

4a) By setting up a check-in build.

4b) You should have someone who actively keeps the PROD branch clean. This person should be reviewing the code that gets merged into that branch. DEV is usually messed up--it's where the integration of many developers' code happens. With a check-in build, the benefit is that you find out sooner rather than later that Steve messed up the build. Look into the "cone of shame" or "siren of shame". It's a "fun" way of keeping the team on top of maintaining a clean build branch.
Fantastic explanation. Thank you for that. Let me read it again to get a better understanding.

Let me ask you this... my manager is asking why we can't use TFS Build service... I think we can. We don't have to use Jenkins or TeamCity.
ǩa̹̼͍̓̂ͪͤͭ̓u͈̳̟͕̬ͩ͂̌͌̾̀ͪf̭̤͉̅̋͛͂̓͛̈m̩̘̱̃e͙̳͊̑̂ͦ̌ͯ̚d͋̋ͧ̑ͯ͛̉Glanced up at my screen and thought I had coded the Matrix...  Turns out, I just fell asleep on the keyboard.
Most Valuable Expert 2011
Top Expert 2015

Commented:
I didn't configure it myself, but I have used TFS and MS Build together for CI. At its simplest, a build server is just a workstation that can run MS Build. You might have to install Visual Studio on that same machine in order to get full build support. You can set up checkin builds with TFS and point them to the build server.
Become a CompTIA Certified Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

Thank you so much. This helps a lot.
One last question:
You should have someone who actively keeps the PROD branch clean.

So, we don't do CI to the PROD branch, correct? Let me show with an example..This is an example of our environment:

1.
Developer1-branch
Developer2-branch

QA-Branch

Prod Branch

2. As we have it now, I manually merge code into QA-Branch.

3. When QA-Branch is tested and all is good, I merge into the PROD-Branch and this is moved to production. PROD-Branch is always good and clean.

This person should be reviewing the code that gets merged into that branch
So, to actively keep PROD-branch clean, we shouldn't do CI to PROD-Branch? I should do that manually, correct?
ǩa̹̼͍̓̂ͪͤͭ̓u͈̳̟͕̬ͩ͂̌͌̾̀ͪf̭̤͉̅̋͛͂̓͛̈m̩̘̱̃e͙̳͊̑̂ͦ̌ͯ̚d͋̋ͧ̑ͯ͛̉Glanced up at my screen and thought I had coded the Matrix...  Turns out, I just fell asleep on the keyboard.
Most Valuable Expert 2011
Top Expert 2015
Commented:
1) In my experience, no. But I think that also depends on how robust your environment is. VSTS, for example, can automate much of the CI process, including requiring sign-offs. You could, in theory, have an end-to-end process that automates how code is moved into production--with the (obvious) exceptions of requiring someone to approve the promotion. TFS may support this, I'm not sure.

2) I think that depends on your project. You could, just as in #1 above, have automated migration to QA. But if you have scenarios where some feature is (mostly) complete, but it can't ship until some other, dependent feature is complete, then you can't just take all changesets. In that scenario, you'd have to cherry-pick which changes get migrated.

3) Probably not, unless you can guarantee that everything that you code needs to be deployed as soon as it is available.
Great explanation. Thank you so much. I'll open another question if I need more clarity.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial