Using Retrace as a key DevOps CI/CD automation tool

Continuous integration and continuous deployment (CI/CD) are integral components of the DevOps practice. Using automation tools is imperative for a team to achieve the agility and efficient delivery goals of DevOps. In this post we’ll talk about how Retrace - in the context of CI/CD, can help a DevOps team achieve operations excellence by leveraging the performance monitoring, error tracing, log management and even the alert notification features of Retrace.

CI/CD is quite a tricky process and the level of sophistication in implementation depends on the readiness of the team, maturity of organizational processes and the availability of automation tools. That is why some organizations implement CI/CD in phases depending on what suits them.

The CI part of CI/CD stands for continuous integration which refers to incremental and frequent code merging. For some organizations, daily code merging is feasible but, in my experience, there are times when they’re not. The feasibility depends on existing coding standards and organizational risk management. Frequent merging requires employment of coding and code versioning techniques that will at least minimize code conflicts even if unfinished codes are merged. The benefit of doing frequent incremental merging is that you never have to worry about doing a big bang merge and the more frequent the merging is the more manageable conflicts become.

Continuous deployment (CD) refers to frequent automated deployment. Ideally, it should also include some automated testing after deployment to give feedback to the development team about the quality of the latest build. In some CD implementations, automated deployments are done all the way to production, while in other implementations where automated deployment to production is just too risky because the team and organizational processes are not yet mature enough, CD are only done up to a certain test environment.

One important factor to consider when implementing CI/CD is the branching strategy of the organization. It is important because it determines the flow of branching, merging, deployment and testing as a version of the application progresses from one test environment and upwards. Below are some of the points to consider when coming up with a branching strategy that is compatible with CI/CD:

Requirements for CI/CD branching strategy (based on Git Flow):

• Supports simultaneous and independent feature level changes
• Supports merging of feature level changes
• Supports merging of different features for integration testing
• Supports merging for full functional testing
• Supports merging back to master
• Supports merging of hotfixes
• Supports rollback

1. Create feature branch from Master
2. Implement changes in feature branch
3. Continuous integration encourages developers to commit their code changes frequently (ideally once a day) with peer review embedded in the process.
4. Coding standards and code versioning techniques can be followed to allow committing all codes frequently even if they're not yet finished. This will eliminate the existence of aging feature branches.
5. Unit testing should also be done at this level (be it manual or automated)
6. If Continuous Deployment is instituted, a scheduled automated daily build and deployment can be triggered probably at night when everybody is done committing their changes.
7. After the automated build is done, automated deployment to the feature test site can be triggered. Tools like Jenkins and Octopus deploy can help automate these processes.
8. At the end of the deployment to the Feature Test site, an automated test script can be triggered to test if the latest changes actually work or to expose breakage in features.
9. If something fails during testing, the continuous deployment tool can be configured to send alert notifications to the development team to inform them that something failed from the nightly build and they need to take a look at it first thing in the morning. This is where Retrace comes in handy. If Retrace is running in the feature test environment, the developers can just analyze the trace, error and log data in Retrace to pinpoint the exact cause of the problem.
10. Retrace can also be configured to raise alerts (optional: send notification) whenever some performance issues or errors are detected during the nightly feature level testing. This is an often neglected aspect of the feature level development and if there are performance issues they're usually just detected during integration testing which usually entails a bigger investigation scope and hence more costly.
11. If the nightly build is successful (no test failures), continuous deployment can proceed with merging all feature level changes in the Integration branch.
12. If there are no merge conflicts in the integration branch, the continuous deployment tool can trigger the automated build and deployment to the Integration test site. Once successful deployment is completed, the integration test script can be executed. Step 9, which leverages Retrace, can then be repeated.
13. Similar progression all the way to production can be repeated. However, full testing may not be desired in the production environment and this is where other features of Retrace can be utilized. In some organizations smoke testing is sufficient after production deployment and in some they simply perform accessibility testing which can be automated using the Website monitoring feature of Retrace.
14. Dashboarding and alert notification of Retrace can be utilized to do production monitoring.

The example above is just one of the many ways to implement CI/CD. The key to definining a CI/CD process that works for you is knowing where you are and where you want to be, because like any transformation initiative, it is more of a journey which requires proper readiness assessment, managed upskilling and never ending process improvement.

If you have questions or would like to talk about other Retrace features, you may book a meeting with your Customer Success Manager (nbontuyan@stackify.com).