Making a software factory from scratch (Part 4): automation
Automation is a crucial point while building a software factory. Consider it as your warranty for an healthy and prosper future and nurture daily, making it evolve for each project you have to manage.
A robust CI/CD toolchain can save time, ensure quality and catch issues before they reach production stage! In early stage of building automation, you will see a huge amount of work that can be done (yes story tellers outside the IT world, automation needs work to be done by humans): to do your best you need to wear a special hat that put yourself as an examiner of your daily coding activities. Ask yourself which ones you can automate and you will discover an endless world you can jump on!
We’re now describing our structured CI/CD toolchain, one for the frontend and one for the backend application we talked about in our previous Medium posts.
- Build: we support for the build phase Maven inside a JRE + Maven container. We prefer of course the use of Maven Wrapper to be integrated together with the code base. Front end code base build is supported using NPM inside a Nodejs container
- Test: using the same container image of the Build Job, we run all kind of tests, using Surefire and Failsafe, generating reports with Jacoco and passing coverage results to Gitlab to integrate them inside our Merge Request. Frontend tests are fully supported running npm tests for our angular project inside the trion/ng-cli-karma container
- Code Quality: we support a specific Gitlab container that runs CodeClimate to generate a report on Code Quality to be integrated in our Merge Request
- Semantic Release: our release are managed by Semantic Release, a Node.Js app that embrace the Semantic Versioning commit style. Semantic Release runs inside a double middleware container (Java + Node) and produces for us a tag for each release, a changelog, a Gitlab Release Page, push the app on the package and container registry. We use a dual pre-release channel strategy for semantic release: we have two protected branching for beta-staging deployment and release candidate deployment. Our master is the only release to production channel. We support multiple release development, bug fixing and patching using git cherry picks.
- Container Scanning: we rely on Clair and Klar projects to scan our containers for vulnerabilities
- Gemnasium: Gitlab’s Gemnasium is the tool we use to check dependency scanning to check for potential security issues inside third part libraries we use in our backend project. This container provide with a useful output that Gitlab publish inside a project report
- Secret Detection: as a part of the SAST analysis, our secret detection Gitlab container scans for all kind of secrets in our codebase and eventually generates a dashboard inside the project pages
- SAST: our Sast container support multiple language targets. For the backend software base, done in Java, Spotbugs (with FindSecBugs) is automatically triggered by the Gitlab SAST container. We can also support NodeJsScan and EsLint with Security plugin for both Node.js and plain javascript projects
- License Scanning: Be compliant to license is not just an issue for Legal Affairs. That’s why we check our compliance, using this container from Gitlab in our CI and checking results in a dashboard
- Deploy: while we’re in the early stages of a deploying scenario, we actually support the container pulling to be run inside an AWS EC2 machine. This machine and a few other infrastructure components are scripted inside a Terraform yaml! (see the IAC section a few lines below)
- DAST: we rely on a pre-built container that use the well known OWASP Zed Attack Proxy (ZAProxy for short) to generate dynamic attack scenarios and eventually reporting vulnerability inside a project dashboard. The attacks run on a dedicated environment and during the release candidate release process
The pipelines described contain parallel and conditional tasks, so that we can trigger a specific job under some circumstances or speeding up a few of them: for example, pipelines triggered under a Merge Request feature implementation are much shorter that the ones in the previous pictures: we do what is really needed at the time we really need it (yes, we love to be lazy this time!)
We have a mixture of pipeline runners (the so called Go app “Gitlab runner”) both on some EC2 machines as well as the shared runners offered by the license plan we bought
Infrastructure as code: We have a separate infrastructure as code project for each business project in our codebase. We use a mix of Terraform and Ansible: the first one enable us to define infrastructure components as a yaml specification. The other one manager our configuration of each single component defined in our IAC (number of nodes, node role inside a cluster, nodes join cluster phase as well as the deploy of a specif set of resources on each node)
Automation is coding and requires a continue “adapt” phase to reach new goals or improve existing ones. We approached to our CI/CD pipelines hoping that we could at least draw a template that brings values to each project we have to face. We understood a bit later that specific yet uncovered automation tasks may arise from a single project, due to the nature of the project itself. After a few months, we can admit that making templates for automation chains it’s a job you can start and it will possibly never end.
One thing instead is about to end: our journey described in these few posts; we really hope you enjoyed this and the previous parts. We tried to share some “bits” of passion we put in each workday, having a constant look at future tasks with an open mind approach and a good dose of smile. Thanks for reading!
Link to previous posts:
Copyright notice: some of the pictures in this article are of their respective owners. We share all of our gratitude to Hanna&Barbera for creating a couple of most beloved childhood cartoons like “The Flinstones” and “The Jetsons”; both of them contributed making us better and happier adults than what we would have been without.