How to Setup Source Control for DevOps and BuildMaster?

We currently use TFS for source control. We use shelvesets to work on individual features and code review them before checking them in to Mainline. This check-in deploys the code to an Integration environment for developer testing. When the code looks good, the one or more changesets that go along with that feature are merged into a Stage branch and a new build is done to deploy to the Staging environment. Here QA tests the feature (and all other features that are candidate for the deploy) and if all is good, then the changeset(s) are merged to a UserAcceptanceTest (UAT) branch and a new build is done and a final test is done here before being deployed to production. Just before a release to production, the UAT branch will contain multiple features ready to deploy. The Production build is changed to point to the most recent UAT branch and another build is done to deploy to Production.

We want to move towards a Continuous Delivery/DevOps approach similar to http://inedo.com/support/tutorials/buildmaster/deployments/getting-started-with-proget-buildmaster-and-otter so that code is not built at each stage.

So if we move to Integration, Testing, and Production stages in BuildMaster, what should our approach/structure be in TFS Source Control and what would trigger the creation of the build artifact to begin the pipeline?

The DevOps approach seems so different from the way we are doing things today and even after reading a lot about it, it is still confusing. There are so many different ideas. There is definitely a pro-Microsoft feel at this company and I am not sure how the Release Management features in TFS 2017 compares to the best practices currently recommended. I know that Git allows one to easily create feature branches, but with Git limitations such as file size is Git superior to the latest TFS? Which is best for DevOps?

I know this post is more about source control, but I think the entire flow is important to better understand how Inedo tools are used for DevOps.

hi Mark, great question.

My team pointed me to your question; I actually talk on this topic quite a bit.

DevOps is really just a buzzword, and everyone (including Inedo) is jumping on it to describe what we do. But ultimately, DevOps is a process improvement designed to improve release velocity (e.g. going agile) through two means:

Automate everything you can
Increase collaboration between teams

Ultimately it's about improving a process of software release. There's a ton of noise about "best practices" out there, and everyone has opinions. But I think the best way to understand these opinions are to get a feel for the underlying process. Two suggestions for that.

Release Management Done Right describes why you should be following a pipeline strategy.
Source Control Done Right goes over how source control should/shouldn't be used, and is still quite relevant today (it was written before "DevOps" was buzzy).

Now, based on your specific situation, my advice is to start simple. Just change-up your TFS version strategy a little bit -- don't build in each environment, but create a build artifact at the start.

You can do this all in BuildMaster. The other tools are nice, but may not be necessary until you run into the problem of trying to have a single tool do it all.