TeamCity
Powerful CI/CD for DevOps-centric teams
Webinar recording: Implementing Continuous Delivery with TeamCity at the Helm
The recording of our February 24 webinar, Implementing Continuous Delivery with TeamCity at the Helm, is now available on the JetBrains YouTube channel.
In this webinar Jeffrey Palermo of ClearMeasure goes over how to set up a continuous delivery pipeline managed by TeamCity, very similarly to how Microsoft’s NuGet team manages NuGet.org. The same chain of tools is used, and the same techniques. You will see, in detail, how to configure TeamCity to run a fully-capable deployment pipeline complete with unit tests, integration tests, acceptance tests, staging, deployment smoke tests, and gated & approved production deployments.
Below is the precise timeline of the webinar and select Q&A.
0:48 – Continuous Delivery principles and practices
1:50 – Overview of the architecture of the setup
4:53 – Continuous delivery pipeline overview
8:35 – Octopus Deploy environments setup overview
9:56 – Test environment overview
11:29 – Running the integration build
12:07 – The build log overview (all the logs are in one place)
12:59 – The artifacts overview
14:45 – The psake build script
15:52 – Connecting the builds together
16:28 – Integration Build configuration overview
21:34 – Deploy to Test step configuration overview
33:20 – Deploy to Test step dependencies and settings
37:20 – Promote to Staging step dependencies and settings
39:10 – Promote to Production step dependencies and settings
41:15 – Running the entire build chain
Q&A:
Q: At the deploy to test stages what test tool are you using to run the 5 tests?
A: Answered by Jeffrey
Q: What are the benefits and downsides of having TeamCity control the deployments versus using lifecycles or similar features in Octopus Deploy?
A: Answered by Jeffrey
Q: Where would the customer run the acceptance test? It seems like a "random commit" to a feature branch would redeploy different code to the test environment? (If you expected latest master to be in TEST)
A: Answered by Jeffrey
Q: Did you ever create different build and package steps specifically for debug and release configuration?
A: Answered by Jeffrey
Q: What happens if a hotfix is made for a previous version?
A: Answered by Jeffrey
Q: We are on java using gradle to build. How can I use the version number defined in the gradle.properties inside of the build step? I want to use variables defined in the gradle.properties inside of the TeamCity build step and not the other way round. E.g. the defined software version defined in gradle.properties should be used as the release number.
A: If you want to affect build number from the build script, you can output service message from the script, like this: ##teamcity[buildNumber ‘<new build number>’] Read more here: https://confluence.jetbrains.com/display/TCDL/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-ReportingBuildNumber
Q: How do we manage Semantic Versioning in TeamCity (build counter is updated for each build by TeamCity)? Do we have to manually keep updating the Major/Minor versions?
A: Answered by Jeffrey
Q: What do you get out of psake that you don’t get from using additional TeamCity build steps?
A: Answered by Jeffrey
Q: How does the production deployment build differ from other builds? I’m guessing we don’t want to rebuild database when deploying to prod.
A: Answered by Jeffrey
Q: Is there a way to manage database changes as part of this continuous delivery process?
A: TeamCity does not know much about changes in database performed during deployment. But there are solutions from other companies like RedGate which probably can help: https://documentation.red-gate.com/display/SCI1/Using+the+TeamCity+plugin
Q: How did you get the footer details updated about the build version and environment updated from TeamCity if all the artefacts where produced in the initial build step?
A: Answered by Jeffrey
Q: How do you manage differences between environments after the build?
A: Answered by Jeffrey
About the presenter: