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.