Since I started my career in IT security 14 years ago, I have worked in different domains including access management, identity management and endpoint management, and in different functions including software development, testing, process automation, release, services, pre-sales, support and management. Throughout my career, I find myself particularly drawn to the area of software delivery. Just as how a pebble dropped in still water has a ripple effect, I have observed that even small changes in the way software delivery is managed can have significant impact on the business, its employees and its clients.
I first observed this when I started my career as a software engineer at a start-up. Source code was checked into a centralized repository and a dedicated machine was used to generate product builds. However, there were no regular builds and what was checked out from the source code repository didn’t necessarily build successfully. And if it was built successfully, it didn’t always run as expected. What previously worked, sometimes no longer did. This resulted in a lot of pain for the developers who had to troubleshoot the build issues, and for the testers who had to retest. Subsequently, issues also slipped past the engineering team and reached our clients, resulting in loss of trust in the quality of our product and damage to our reputation. To remedy this, we started to adopt continuous integration practices by setting up nightly builds and executing unit tests and source code analysis as part of the build. We also leveraged runtime analysis and UI automation tools to automate functional test cases. Such practices allowed us to detect and resolve issues as early as possible in the software development process. They also allowed us to better measure the quality of a build.
Other than the obvious impact on quality and turnaround time, other impacts of improving the software delivery process might not be as direct or obvious. In one particular situation, there was a critical time-sensitive monthly release that required 15-20 software engineers working continuously for around 24 hours, in addition to other time-sensitive releases throughout the month. Each release involved a significant amount of manual effort and the work involved was not interesting, which were some of the factors that led to high attrition and low morale. To turn this situation around, the team designed and built an automation framework that generated most of the content required for release and deployed the content to a production-like environment for testing. With this automation framework, just 5 engineers were required to work for less than 9 hours to carry out the critical monthly release. Releases became much less onerous with significantly less issues reported, so the engineers could divert time away from releases and instead spend more time on other projects. What’s more, the engineers were proud of what they built and were highly motivated to further enhance the automation framework. The team were also able to commit to a shorter turnaround time with high confidence in the quality of the release. These left a deep impression on the management team, which entrusted the team with more challenging projects. This, in turn, meant more interesting work for the development team. Consequently, automating the software delivery process not only helped to improve the reputation and credibility of the development team, it also helped to improve its morale.
Against the backdrop of these experiences, in my role as the DevOps, QA and Release Manager at V-Key I apply the same philosophy which is to automate the build, deployment, testing and release processes wherever we can. This allows us to release our software as quickly as possible with minimum manual effort, and with high confidence in the quality of the released software. I believe that doing so will not only benefit our business and employees, it will also benefit our clients.