STAMINA is an ambitious project boasting a large consortium of 39 partners and highly complex tools and trials across 12 countries to improve pandemic preparedness and response among national planners and end-users. Given the scale and complexity of the project, STAMINA software developers leveraged the Continuous Integration (CI) and Continuous Delivery (CD) engineering methodology to deliver within the stipulated conditions and exceed expectations.
17 months after the STAMINA project began, the development of the STAMINA toolkit included the CI/CD engineering methodology to allow flexibility for effective testing and integration to ensure swift delivery to trial sites in 12 countries for the tools to be evaluated.
Why was CI/CD engineering methodology utilised?
In technical terms, CI/CD engineering methodology was utilised to periodically commit, build and test the source code and the artifacts developed within the scope of the project. During the software development cycles of STAMINA, CI/CD pipelines deliver and deploy functioning applications in servers that have been explicitly prepared and dedicated for integration testing purposes, referred to as the Development & Integration Environment.
In other words, the software Deployment & Integration Environment acts as a testing sandbox, which can accommodate deployed instances and effectively integrate, test and release all the software services of the STAMINA platform. Once all the individual modules and their interactions have been successfully and adequately tested, images of the modules stored in a registry will be transferred and deployed on the pilot sites to be evaluated during the project’s trial sessions.
STAMINA partner, Netcompany-Intrasoft, played the main role in defining, assembling and maintaining the STAMINA CI/CD technology stack and the Development & Integration Environment.
What is CI/CD in software engineering?
Continuous Integration (CI) is a coding philosophy and set of practices that drive development teams to implement small changes and check-in their code to shared version control repositories frequently. Every commit corresponds an automatically triggered build that takes the entire code base, builds it, runs all the unit tests, performs code validation steps, and generates the specified packages and artifact at the end along with a build status and a log. All throughout this process, automated tests check that the output application does not demonstrate unexpected behaviour or breakages despite the new commits that have been integrated into the main branch of the code base. Should a test fail, the build chain of events is broken for the entire team before deployment. To fix the build, the updated code is required to run through the same process. This discipline generates a fast feedback loop.
In simple terms, Continuous Integration (CI) aims to speed up the release process by enabling teams to find and fix bugs earlier in the development cycle. As a result, the development process will be improved, dedicating less time for backtracking and more time for development and integration.
Continuous Delivery (CD) is an extension of Continuous Integration and the next step in the pipeline. Delivery phase is responsible for packaging artifacts following changes and deploying them to a production-like environment. Along the way, automated integration and acceptance tests take place. This build phase should be kept ‘green’, meaning that the artifact should be READY to be deployed to production at any given time. This discipline minimizes the risks associated with releasing software and new features, by ensuring that every change made to the underlying code of an application is releasable – meaning that each update is small and can be delivered to users more frequently.
An additional interesting part about working in a Continuous Delivery environment is that there are two vectors making an organizations’ Mean Time To Recover (MTTR) shorter.
- Firstly, once an alert for a failure state has been received and a remediation action has been devised, it can be treated just like any other change and rolled out quickly without breaking the usual process.
- The second and less obvious benefit is using Continuous Delivery to find the actual cause of failures. For instance, by overlaying a graph indicating a problem with the deploys that happened in that same time – window, it is easy to figure out exactly which commit introduced the error.
The STAMINA Development & Integration Environment
The Development & Integration Environment consists of three instances that have been deployed to Hetzner Cloud in order to ensure that resources can be freely allocated to and from other computers by the software, enabling maximum utilization and helping to prevent crashes.
Additional virtual machines host the STAMINA CI/CD tools, i.e., pieces of software that automate the periodic deployment of the STAMINA modules on the Development & Integration Environment.
From a technical point of view, the Development & Integration Environment consists of three virtual hosts, which are, in essence, cloud servers instantiated on a public cloud provider, named Hetzner Cloud. To decide on the number of cloud instances required for the deployment of the STAMINA toolkit and the exact hardware specifications of each instance, a detailed requirements documentation has been prepared. Additional virtual machines host the STAMINA CI/CD tools, i.e., pieces of software that automate the periodic deployment of the STAMINA modules on the Development & Integration Environment.
Key Technologies and Tools
A summary of indicative technologies and software tools that synthetize the STAMINA Continuous Integration/Continuous Delivery stack follows below:
- Git [1]: A free and open-source distributed Version Control System (VCS). It is used for tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. It has been designed to handle everything from small to very large projects with speed and efficiency. A Git repository (or repo for short) contains all of the project files and the entire revision history.
- GitLab [2]: A web-based open-source Git repository hosting service. It offers a graphical interface with several built-in features, such as version control, issue tracking, code review, wiki, etc. Multiple developers can concurrently create, merge and delete parts of the code they are working on independently, at their local system before applying the finalized changes to a shared GitLab repository. GitLab offers the option of self-hosting a GitLab server on-premises, however, for the needs of the STAMINA project a GitLab instance hosted on gitlab.com has been deemed sufficient, provided that the access to the code be restricted to the project developers.
- Jenkins [3]: An open-source automation server that acts as the principal Continuous Integration/Continuous Delivery server, responsible to automate the parts of software development related to building, testing, and deployment of applications. Some of the tasks that can be automated through Jenkins include software builds, unit testing, packaging, containerization and pushing of container images to a Container Registry.
- Docker [4]: A set of Platform-as-a-Service (PaaS) products that use OS-level virtualization to deliver software in lightweight packages called containers. Docker can package an application and its dependencies in a virtual container that can run seamlessly on any Linux, Windows, or macOS computer. This enables the application to run in a variety of locations, such as on-premises, in a public cloud, and/or in a private cloud.
- JFrog Container Registry [5]: An application that implements a private Docker Registry in which one can store and distribute the Docker images of the projects’ artifacts. It is used to securely control where the images are being stored awaiting containerization, thus integrating image storage and distribution tightly into the STAMINA development workflow. For the needs of the STAMINA project, a self-hosted JFrog Container Registry instance has been deployed to Hetzner Cloud.
- Portainer [6]: An open-source tool for managing container-based applications in various virtualization environments. It can be used to set up and manage the environment, manage containers lifecycle, monitor application performance, triage problems, and enable role-based access control. For the needs of the STAMINA project, a Portainer instance has been deployed to Hetzner Cloud.
- Slack [7]: A messaging platform, as a Notifications Management, has been setup to facilitate the communication amongst the development teams of STAMINA project and to provide notifications on development events. For the needs of the project, a STAMINA dedicated workspace has been created and configured in slack.com.
- NGINX [8]: An open-source web server application configured as a reverse proxy for the different STAMINA Continuous Integration/Continuous Delivery services. A reverse proxy provides an additional level of abstraction and control to ensure the smooth flow of network traffic between clients and servers and increase security by protecting the identities of the different Continuous Integration/Continuous Delivery platform services. For the needs of the STAMINA project, a NGINX instance has been deployed to Hetzner Cloud.
[1] Git official website: https://git-scm.com/
[2] GitLab official website: https://about.gitlab.com/
[3] Jenkins official website: https://www.jenkins.io/
[4] Docker official website: https://www.docker.com/
[5] JFrog Container Registry official website: https://jfrog.com/container-registry/
[6] Portainer official website: https://www.portainer.io/
[7] Official Slack website: https://slack.com/intl/en-gr/
[8] NGINX official website: https://www.nginx.com/