As the IBM Maximo team builds on Agile best practices to faster and higher quality development, we are looking forward to implementing many improvements around Continuous Delivery (CD). In it's most extreme, CD is a fully automated code delivery and test pipeline that will take a code change, through all the build, test, and promotion steps and make the change available without any manual intervention, and with full visibility to the team. If there is a problem with the change, the line is stopped and the defect routed automatically so it can be quickly repaired and complete delivery. Continuous deployment is similar to continuous delivery, but also includes automation to deploy the fix directly into production.
Continuous Delivery allows Maximo to further improve on common objectives around speed and quality. Maximo's implementation of CD will focus on fully automated development and test pipelines for day-to-day delivery of code, and minimize or eliminate post sprint testing.
In the past, delivering significant new function, required a lot of test time and effort before delivery. To maximize the benefit of those large test efforts, we tended towards larger, longer projects. We had a lot of feedback from customers wanting needed function sooner, quality concerns over the amount of change, and the expense of adopting so much change at once. Adopting Agile best practices allowed us to start reducing waterfall delays, shifting development and test left in the process, and increasing quality while delivering a lot of great product improvements.
Going forward into CD, we are dramatically improving our automation (Unit Test, Build, Provisioning, System Test ...) while introducing new pipeline automation using Urban Code, Chef, Jenkins, and other tools. The pipeline automation allows us to connect all the steps along the dev-test process together, provides visibility to the team, and eliminates several manual work flows.
So that's a lot of nice technology, and efficiency, but what does that mean for impact?
For projects, it means:
- Reduce simple change delivery effort (the amount of effort to deliver a small, 1 line change) from a week or more to a day or less,
- A massive, 3x increase in automation, to increase quality, and reduce time
- Reduce post development testing from several person-years (PY's) of effort, to a couple person-months (PM's) of effort.
For customers, it means:
- Faster delivery of important requirements
- More product improvements from more efficient projects
- Smaller, more consumable deliveries
- higher quality from better development processes, and much more testing
Overall, we'll be shifting from very large projects, like Maximo 7.6, that took years to deliver, with a mountain of content, to faster releases that take a few months to deliver, with less content, and keeping a high level of testing, and quality assurance. Customers can still take content on a schedule that fit's their business, and will have much more visibility of incremental changes as they come out, as well as the benefit of field feedback as deliveries come out.
Please watch for more information as we adopt Continuous Delivery. If you have questions, please contact Bjorn Kutz (firstname.lastname@example.org), Fernando Giglio (email@example.com) or Jenny Wang (firstname.lastname@example.org).
About the Author. Bjorn Kutz is the IBM Internet of Things (IoT) QA Program Director for Maximo. He works with a fantastic Continuous Delivery team including Fernando Giglio - Development and CD Manager, Jenny Wang - Technical and CD Lead, and many other CD enthusiasts across the Maximo Team. Bjorn is also a regular contributor on the Maximo Quality and Test Community.