There are of course many other ways to solve feature branch deploys, but we wanted to have the manual step to choose what branch to deploy where and with what config.įirst step was to set up a new build template in Teamcity. The reason we wanted to have these five preconfigured projects was to have a dashboard available where we could easily see what feature branch was deployed where. This would then create a release and deploy to one of five preconfigured Octopus Deploy projects, which did the rest of the job by setting up the IIS and deploying the Nuget package published by Teamcity. Which config transformation file to use (stage, pre-production, production).What we wanted to achieve was being able to trigger a build manually in Teamcity, by stating: The prompted variables in Octopus Deploy have to be set up directly on the project, not in an included variable set.Variables can be passed from Teamcity to Octopus Deploy only if they are set up as prompted variables in Octopus.Custom builds can not trigger another build using the Finish Build Trigger in Teamcity.Since we mob program we mainly work directly in the master branch, but sometimes we do bigger features that need to be looked at or tested outside the team.
We decided to try and find a way where we could quickly deploy any given feature branch if we needed to. But that can be tricky to implement, and almost always needs code cleanup after the feature is released. Sooner or later, when you have a website in production, the question arises: how to develop new features without deploying partly built features along with bug fixes? Feature toggles might be the way to go.