Suggest Best Setup Approach
I'm looking for advice on the approach to setup TeamCity along with TFS 2015 and Octopus.
We have multiple branches, dev, main and release (currently we create a release branch for each release). Our procedure is to develop in dev and deploy to dev environment. When we are ready for testing we merge from dev to main and deploy to test from main. When happy we create a release branch and deploy to live from the release branch. This is a manual process and we tend just to copy from main environment to live then create the release branch. Hotfixes are done on the release branch and deployed to live. We then merge back to main/dev.
I'm totally new to this and so far in a VM playground I've setup TFS2015, TeamCity and Octopus and can check-in to TFS, build on TeamCity and deploy from Octopus.
1. I'm unsure how I should setup TeamCity and Octopus to work with multiple branches? Multiple projects for each branch and generate different artifacts?
2. I have a TFS VM, I plan on installing TeamCity and Octopus on this along with the build agent. Is this a bad idea? Should I create a new VM just for TM and Octopus?
Probably daft questions to those experienced with CI but any best practice or help would be appreciated. I'm willing to change branching strategies if it makes sense to.
Thanks
Please sign in to leave a comment.
It's hard to provide specific suggestions to questions like this, because we don't really know all of the specifics of your projects. Based on our experience it make sense to do the following:
- setup separate project for development branch - your developers most likely will work with dedicated set of build configurations most of the time, for instance, to build source code or run different tests; usually developers are less concerned about deployment
- setup separate project for deployment - deployment often requires special credentials or permissions, as such it is easier to control access to deployment tasks if they kept separate from development project; you can use TeamCity artifact dependencies to provide artifacts from a build configuration which builds your project, to deployment build configuration
- try not to use specific branch names in TeamCity configuration, it is better to define a parameter with branch name and then reference it in various places
- build configurations which build your project from source code in different branches tend to be similar, to avoid settings duplication you can use templates
- try to avoid duplication of VCS roots - they also support parameters, so you can define a parametrized VCS root once, and then use it with different parameters in various places
Thanks for the reply Pavel.
I've come to a similar conclusion and have decided to change my branching approach, I'm currently testing/setting up the following approach, please let me know what you think?
-TFS
Two branches, master and release. Day to day changes are checked into master. When release for a release master is merged into release and given a version number.
-TeamCity
One project with two builds, build-master and build-release.
build-master - will build and push the package to Octopus API on each check-in, will use checkout rules to checkout from master branch. Octopus will then deploy automatically to our development servers.
build-release - when we decid to create a release we will branch the master to the release branch and give the sub folder a version number for example release/release-1.0.0. Then we will amend the build-release configuration and the checkout rule and the path to the solution to point to the new version. Might be able to use a variable so only have to change in one place.
-Octopus - as you suggested we would have two projects, the first to deploy to development and would have the package pushed to it using the API. The second project would be manual, so would pick up the package from the teamcity external feed. We could then deploy the release branch to our test servers then assuming ok we would promote this release to the production servers.
So it's almost build one version of the binaries and deploy everywhere. Any suggestion or criticism?