Automating Continuous Delivery(CD) via TeamCity and Jenkins
Typically a product would use either TeamCity or Jenkins for building artifacts and deploy them to various environments such as Dev, QA, Stage and Prod. However there will be certain scenario’s where multiple build and deploy tools would be used in order to build, deploy and determine the quality of various components of the same product.
This case study highlights –
- Possible scenarios of why a product would end up with multiple build and deploy tools.
- Automating Continuous Delivery via TC [Build] and Jenkins [Build verification tests] together.
Possible scenarios of why a product would end up with multiple build and deploy tools
- Legacy code , Product acquisitions
- Integrating a newly acquired product into mainstream business is the first problem an engineering team would face. In additional to that comes database migration, tech stack upgrades and last but not the least – streamlining the deployment process.
- Same applies if a product upgrades the technology stack to support business [aka performance, user experience etc] there will be certainly parts of the system that would not upgrade and become legacy which will be hard to maintain.
- Tech debts: Test coverage challenges.
- Different practices used in early stages of Product development
- Kareo as an example: Last month, application was broken down to microservices, however, core part of the product with a lot business value was left with the monolithic thus calling it Legacy. The legacy is still a biweekly release and CD is a nightmare. In legacy systems, as the product delivery is not possible in CD Process, products might end up in maintaining TeamCity or builds management and Jenkins for Automation suites execution which in general executes daily on different environments.
- Microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
- Software built as Microservices can, by definition, be broken down into multiple component services. So that each of these services can be deployed, tweaked, and then redeployed independently without compromising the integrity of an application.
- When Products having both legacy systems and microservices, they might end up in maintaining both build systems which development might use one and QA team might use the other one.
- In this case, to achieve Continuous Delivery, the build systems have to handshake with each other to build deployable artifacts, test/validate in the CD pipeline in an automated way.
Problem / Scenario:
Consider a TeamCity build is ready to deploy to QA, Stage and Production environments in CD Process.
But as Automation scripts are to be executed from Jenkins, for promoting the build to higher tier environment’s, we will have to perform these steps :
- Trigger QA Build in TeamCity [Manual]
- Manually to verify the build/artifact that was deployed to QA [Manual]
- Wait for the deployment to complete in QA environment
- Trigger Jenkins Job (which internally calls, executes a web automation script) and wait for Automation Scripts results in Jenkins
- If the build passes, move to next environment and repeat the same process for STAGE And Production environments.[Manual]
In order to truly achieve CD, the minute the code is merged to default/master, a dev build should trigger in TC. Once the build is done, the artifact should be deployed to QA automatically by TC, Team city should trigger Jenkins job to verify the build and move on to higher tier environments without manual intervention.
The bottleneck in the current situation was – “How do we integrate TC and Jenkins to achieve automated CD?”
Using Jenkins API, we can perform a handshake between TeamCity and Jenkins.
Below are the steps for integrating TeamCity with Jenkins
- Once a build is available in QA environment, Jenkin’s API will be used to execute automation script which will be triggered programmatically via TC.
- Once the above step is done, TeamCity has to continuously monitor Jenkins jobs for the automation results.
- Jenkins API gives information about the current job’s status(fail or pass)
- Get the status of the Jenkins job(completed or not) using the API
- Based on the status, polling happens till the completion of the Jenkins job
- We can set the time for polling so that if the scripts are not executed in specified time, we can fail the deployment.
- Once the above program is ready, convert it to a jar which can be called from TC Build Steps
- We need to set Build configuration settings for each environment in TeamCity.
- Set the Jar file as Artifact Dependencies under TeamCity
- Set the Finish Build Trigger under Triggers section so that the current build waits until the completion of the previous environment build successful deployment.
- Add a Build Step to Run Jenkins Job and get the Status
- Based on the status of Jenkins job, build can be moved to next environment
- Same steps has to be added for Stage and Production as well.
- Once TeamCity is configured as above for each environment,
- It will be easy in deploying the build from QA to Production directly without any manual intervention
- For each environment automation scripts will be executed automatically by triggering respective Jenkins job from TeamCity and will wait for the results from Jenkins before moving to next environment’s build deployment.
- The same is depicted here.
- Video URL for the above process: https://www.youtube.com/watch?v=nwM5ZA-uwjA
To conclude, we can make TeamCity and Jenkins handshake each other which will enable us to achieve Continuous Delivery. So with this automation in place all we need to do is commit the code and the rest is taken care automatically.