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

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

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.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CamilliaAuthor Commented:
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.
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.
Bootstrap 4: Exploring New Features

Learn how to use and navigate the new features included in Bootstrap 4, the most popular HTML, CSS, and JavaScript framework for developing responsive, mobile-first websites.

CamilliaAuthor Commented:
Thank you so much. This helps a lot.
CamilliaAuthor Commented:
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:



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?
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.
CamilliaAuthor Commented:
Great explanation. Thank you so much. I'll open another question if I need more clarity.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.