CopernNet : Point Cloud Segmentation using ActiveSampling Transformers
In the dynamic field of railway maintenance, accurate data is critical. From ensuring the health of ...
Continuous integration enables your software developers to be more effective by focusing on their core task: improving your software product. It bears the promise of catching bugs fast, avoiding big software overhauls and enabling your team to (better) work in parallel. This reduces cost, time-to-market and avoids brand damage due to substandard releases.
In addition, it is often pitched as an important stepping stone towards continuous deployment and DevOps. This article zooms in on the advantages of using CI in your team, both for standalone usage and as a stepping stone towards a full DevOps chain.
What is continuous integration?
Continuous integration is the whole process where every software modification is thoroughly and automatically checked against your predefined, minimal quality standards. Modifications that adhere to these standards are ready to be integrated – ideally automatically – in the next stable version, while modifications that are not up to standards are prevented from being merged. The figure below illustrates how continuous integration fits into the software development process: it needs a development methodology that continuously delivers new software modifications into a ‘next-gen’ version (this does not necessarily need to be Agile) and is a requirement for evolving towards the continuous delivery of new software releases.
The figure shows another interesting dependency for continuous integration: all stages up to ‘test’ – code quality, build system reliability & control, integration of new bug fixes or features and testing – must be at least ‘good enough’ – not necessarily perfect – in order to achieve maintainable, cost-effective continuous integration. Additionally, it illustrates the order in which you want to achieve a sufficient quality level of each block, as each block is a necessary condition to have in place before moving on to the next one. What level is sufficient for each block differs widely and is very application-specific. Higher levels of quality for each block typically yield higher long-term gains.
Quality standards
While – theoretically – your minimal quality standards can be as simple as ‘the software must install correctly’, in practice most quality standards will need at the very least a decent test coverage (covering the whole so-called ‘test pyramid’), enabling trivial quality standards like ‘the software should never crash’ or ‘core functionality X must be thoroughly tested’ to more extensive ones like ‘real-time process Y should run below 1 s on machine Z’, ‘we want to use at most 42 MB of RAM’ or ‘no memory leaks please’. Other often used quality standards involve a review by a minimal number of peers, maximum severeness level for static code analysis or a list of platforms the software must support.
Advantages of continuous integration
The next version is always releasable
Rather than checking your minimal quality standards after a code freeze, they are checked continuously. Features may still miss in the next version, but the ones that are integrated, actually work. This is a must have for teams wanting to evolve towards continuous delivery.
Finished features are finished
Feedback on the quality of a new feature is checked before it is in the next version, not weeks or months after it has been added. This avoids ugly surprises during the release candidate window where a new bug mandates a complete feature redesign and its associated costs. This minimizes uncertainty in your release schedule and avoids software engineers checking off a feature too eagerly.
Monitor your KPIs
Continuously monitoring of the software enables fine-grained tracking over time of certain key characteristics, like the test coverage, maximum RAM usage, startup time etc. This allows teams to catch trends quickly (‘why is our software steadily becoming slower?’) and visualizes subpar or excess characteristics (‘our test coverage is 80%, while we require at least 60%’).
Additionally, most CI tools offer ways to integrate their status into dashboards for a better status overview.
Your team works more effectively
Writing software that is up to your minimal quality standards often requires a lot of application-specific knowledge. This knowledge is often distributed and gained over years of developing the product. This makes it difficult for less experienced team members to get up to speed with your application development and makes senior team members prone to forgetting or skipping certain criteria.
Continuous integration improves this situation in several ways:
- It checks all the criteria all the time. It is impossible to (unintentionally) forget or skip one.
- The burden of checking all criteria all the time – often a time consuming task on a single work station – is offloaded to server infrastructure, allowing your team members to only check the most relevant criteria and then move on to their next work item.
- Your CI system is the culmination of your team’s application-specific knowledge: it is collected, merged and maintained into a single, self-documented system. Knowledge important enough to be cultivated is kept, while irrelevant knowledge is archived in your version control system. Moreover, it is guaranteed to be up-to-date, as it is checked with every modification.
Uniform release procedure
Releases are built and assembled by one central entity – ideally starting from scratch in a minimal environment – resulting in a consistent, fully self-documented, always up-to-date release procedure. This minimizes the potential impact on the release from other software present on various employee workstations. As a bonus, all team members can trigger a release.
Challenges for implementing continuous integration
Truth be told: there are a couple of challenges to overcome before you benefit from the above advantages.
Defining minimal quality standards
A majority of software teams have no idea what the minimal quality standards for their software are. They fall back into a ‘best-effort’ approach that is defined by time and technical constraints, which can vary significantly among team members. Standardizing the entire team on realistic, specific and measurable quality standards has a lot more benefits than simply enabling continuous integration. Furthermore, it enables a gradual increase of these standards over time.
Team mindset
Continuous integration requires a mindset towards delivering quality work. Improving, extending and checking the continuous integration framework must become a natural, inherent part of any software task, just as much as writing production code and tests. As such, these improvements must happen in lock-step with these activities.
This implies an important change in priorities: a failed check for an already integrated feature is more important to anyone in the team than to finish a new one. While this may seem like a limitation, it does put the priorities straight for the entire team: fixing the current state of the software is more important than adding new features to a broken application.
Skipping testing
Often, continuous integration is implemented while the ‘test’ building block is insufficiently in place. As mentioned earlier, this puts a significant limitation on the quality standards that can be enforced in practice. The result is often a rectification of priorities: in order to enforce a quality standard, a whole suite of testing is put into place. Teams hit by this rectification often experience getting started with continuous integration to be difficult and time-consuming.
It seems like you're really digging this article.
Subscribe to our newsletter and stay up to date.
