The term DevOps is rather recent on the global IT landscape, but it’s already risen to the top among the most effective industry practices. According to the Gartner IT consultancy, in 2015, 25% of 2,000 biggest world corporations were moving towards a DevOps approach. More than a working method, it is above all a cultural change that aims, as its name suggests, to bring development and operations closer together. DevOps has a twofold objective: to speed up update deployment and ensure high quality levels.
Its secret lies in cooperation and sharing: developers and system operations managers work together to provide continuous software delivery. Development cycles are shorter, quality assessed throughout the project and deployments more frequent.
“DevOps is an understood set of practices and cultural values that has been proven to help organizations of all sizes improve their software release cycles, software quality, security, and ability to get rapid feedback on product development.”— Puppet Labs, “2017 State of DevOps” report.
BlueMind has chosen to implement a DevOps approach through a process of continuous integration. Let’s have a look at what this entails.
A new paradigm
Traditionally, developers didn’t share their work with the rest of the team and would go off on their own for long periods of time. They’d only integrate code modifications when their work was done. Developers didn’t actually know what the true impact of an update had over the whole application. As a result, issues were only identified down the line and they were difficult to pinpoint, thereby delaying delivery.
As for operations departments, they sometimes had to wait several months for testing and deployment to satisfactorily respond to user needs, which by then had probably changed. Both teams – development and operations — didn’t have the same objectives and therefore didn’t have the same priorities.
On paper, software requirements are clear, set in advance and static. Developers work on the code, and operations teams work on implementing it on the company’s systems. On paper, that is.
In the real world, IT evolves so quickly that it is impossible for project specifications to stay the same throughout. For software publishers, the “project” never ends! Software must be released as quickly as possible, but it must also evolve constantly. Adding new functionalities must as easy as possible and bugs must be identified so that they can be fixed. New features must not disrupt what already exists and take into account all possible configurations and situations. There’s no D-day for product deliveries like in the past.
DevOps practices – including continuous innovation – aim to put an end to the conflict between Dev and Ops – and find a balance between innovation and stability.
DevOps: improved dialogue between teams
The DevOps approach is about setting up an overarching process involving everyone concerned, whatever their initial role. No more isolated and hyper-specialised individuals, development and operations teams work together throughout the entire life cycle of an application, from design and testing to deployment and operation.
Teams share many responsibilities and combine workflows. This limits efficiency losses and saves time.
“At BlueMind, no one is moving forward by themselves. We encourage collaboration and sharing to promote operational efficiency. We have a common objective and a plan – defended by the product or feature owner – we work towards together. The whole team can keep up with projects, ideas and everyone’s stumbling blocks”.
Dominique Eav – Quality Bandmaster at BlueMind
The time spent sharing know-how, ideas and knowledge should largely be made profitable by the efficiency gained in delivery quality, anticipated issues/errors and faster troubleshooting.
Continuous integration
Put simply, integration consists in putting together pieces of code and getting them to work together. This often takes great dedication! Integration often involves multiple projects and environments, each environment involving organising the module concerned differently as well as construction, testing, validation and deployment phases. Continuous integration solves these problems by involving all stakeholders in a project from development to operation.
Continuous integration is the set of practices that allow developers to integrate code changes into a centralised repository regularly, automatically create and run testing sessions, and then deploy build results if all lights are green. This process makes it quicker to detect and fix bugs, helps improve quality and reduce update validation and release time.
Test results history.
For any given test, you can see what’s happening now and in the past. A “failed” on a test that passed before points to a regression
Every time the source code is modified, the result is checked for regressions or defects in the untouched parts of the application. Bugs are identified more quickly and therefore fixed more quickly. Validation and release time are reduced and, obviously, final quality is improved.
“We largely use the principle of pull requests. This mechanism allows developers to share and validate their work whether it’s finished or not. The developer may submit a pull request at any time for review by the people involved. It’s a lot more than mere validation – it’s a genuine discussion about the technical choices for the functionality under review. That way, we make sure that the whole team stays up to date with technical evolutions and choice integrity”
— Dominique Eav Quality Manager at BlueMind.
Dashboard on the build of a (master) branch
This diagram shows the test results for the different build stages and earlier builds
Automation: the cornerstone of continuous integration
Compilation, one-off and operational tests, product validation, performance tests… all are key but time-consuming activities, not to mention susceptible to human error, which is always a possibility. The principle of continuous integration relies on test automation to save time and ensure maximum quality levels.
When a developer writes code, the tool automatically checks that it complies with common rules set for the whole team. This procedure ensures the quality of the newly-written code and its stability over time as it complies with development best practices.
This code analysis tool shows the test coverage on the code. You must seek the highest coverage possible.
BlueMind uses Jenkins to drive its continuous integration chain. This software tests and reports changes made to a large base of code in real time to detect problems quickly.
We use Jenkins to build and test our development branches (features or corrections) whose changes continuously integrate our release branches (3.0, 3.5, 4.0), on all supported Linux distributions (8 for BlueMind 3.5.9). The BlueMind core comprises more than 500 modules and interacts with many AddOns you can find at the Marketplace. These have also been built, tested and deployed through our continuous integration chain and are subject to the same compatibility and quality constraints. More than 3,000 tests are carried out on every build. Such a degree of complexity would be impossible to manage manually! What’s so clever about continuous integration is that tasks automatically run one after the other as we aim for process industrialisation.
“Our approach is consensual and pragmatic. We implement and improve our processes to make our team members’ lives easier, as opposed to complying with an imposed set of project specifications. The resulting automation allows us to be fast and helps potential problems to surface as early as possible. Each brick in our continuous integration chain is a safety belt.”
— Dominique Eav Quality Manager at BlueMind.
This static code analysis tool assesses classes: it measures technical debt, i.e. the time required to fix problems found in some part of the code.
In addition to eliminating tedious tasks, automation makes the deployment process more reliable while increasing delivery frequency. Teams can then concentrate on improving existing features or quality control rather than performing tests manually.
Specific benefits
With continuous integration, development teams save a huge amount of time as each software modification is immediately tested. By compiling code regularly, software modifications that cause trouble are quickly identified. Developers have a quick overview of the regression they’ve caused. Conflicts between the software and the ecosystem it will be operating in are detected early on.
Throughout the development and deployment process, the entire team works very closely towards a common goal: the success of the project as a whole, not just their own part.
When the whole project team is agile, a new functionality or a bug correction can be released quickly – or cancelled as the case may be. A working version of the software is always available and there’s no need to wait for the software to be released to find out whether it works. With BlueMind, we first release new features or software patches internally. This process is called “eating your own dog food“, which means that we are the first ones to use our solution.
On the client side, continuous integration makes deliveries faster with more frequent updates while ensuring the best quality levels possible.
In conclusion
Installing a scheduler like Jenkins isn’t enough to implement continuous integration. One of the Manifesto for Agile Software Development’s statements is that individuals and interactions are valued over processes and tools. A DevOps approach is about involving everyone’s responsibility. The DevOps culture implies adopting a transparent approach based on communication and collaboration between IT/Operations and development teams. It is a great approach for constantly-innovating businesses!
BlueMind was built on these principles from the start to ensure the best quality levels in a complex environment. The agility this gives us enables us to deliver first-class, stable products by industrialising processes between operations and development.
