LESSONS LEARNT SINCE 1ST OCTOBER 2021
- Continuous Integration
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
The goal of continuous integration is to minimize the impact of problems found when integrating different software components together. A regular integration cycle ensures that the components are integrated together in small pieces. The advantage of this approach is that you don’t have to deal with large problems which might be troublesome to solve. Instead, you will face only smaller problems which in general should be easier and faster to solve.
The true test which reveals if you are really doing continuous integration is this: What do you do when your build fails? If you are doing continuous integration, you will start fixing the problem as soon as you are aware that it exists. This is the condition which must be fulfilled before you can claim that you are doing continuous integration without lying. Keeping the build green should be of higher priority task than any other task in software development.
- Fix Broken Builds Immediately
A key part of doing a continuous build is that if the mainline build fails, it needs to be fixed right away. The whole point of working with CI is that you’re always developing on a known stable base. It’s not a bad thing for the mainline build to break, although if it’s happening all the time it suggests people aren’t being careful enough about updating and building locally before a commit. When the mainline build does break, however, it’s important that it gets fixed fast
Learning that fixing build failure is of higher priority task in software development. This doesn’t mean that everyone on the team has to stop what they are doing in order to fix the build, usually it only needs a couple of people to get things working again. It does mean a conscious prioritization of a build fix as an urgent, high priority task.
Work Done
-
Increased the test coverage for REST API
-
Resurrected CI for QA Framework module. While investigating why CI for the module was failing since the 1st October, along the way had to learn Bamboo configurations for the module. Reaching out to the community for support was so beneficial in figuring out the issue and resolving the problem that had persisted on the module for over 17 days. And now the CI is green!
During the process, I also learnt the handshake process that takes place during server certificate verification when CI is taking place. curl performs SSL certificate verification by default, using a “bundle” of Certificate Authority (CA) public keys (CA certs) and these certificates expire after a specific period of time because HTTPS server uses a certificate signed by a CA represented in the bundle. Thanks to @ibacher who gave more scope on this subject through his comment. Great thanks to @dkayiwa @sharif @mozzy for your support during the process of resurrecting CI build.
Work To Do
The remaining phase of the month will focus on finishing the remaining REST API tests and also looking for a smart way of integrating deployment Technic on qaframework module for all the PRs so that a committer or even a non-technical person can just press a button and the changes are deployed on the server, run against the existing code base and returns the build result. When this is effected, will then look for a way of integrating the same in other openMRS repos.
Great thanks to @jennifer @grace @janflowers @dkayiwa @ibacher @christine @mozzy for your continued guidance and support in my fellowship journey!!