There was a time, not so long ago, when the lifecycle of a software application, from the end user’s perspective, was long periods of inactivity punctuated by occasional, incremental releases, each with a few new features and a bunch of new bugs.
This model of software engineering was known as the waterfall model, in which each version of an application was a project unto itself. Once one version was complete and released to the end users, the development team would start over again on the next version.
Even with the widespread adoption of the agile software development methodology, application lifecycle management still relied largely on iterative cycles. The difference was that the cycles were broken into sub-cycles, or sprints, of two to four weeks’ duration. The product of each sprint was functional and tested software that in theory could be released to the end users. Often, however, the team would wait until several sprints were complete before releasing the software.
That mindset is now changing throughout the industry with the rise of the Development Operations (DevOps) software engineering practice. An increasing number of software development organizations are making the transition from iterative to continuous software development. This article discusses the main elements that support this transition:
The twin concepts of continuous integration and continuous delivery make up the core of the continuous development model.
The key to successful CI/CD is having repeatable processes. This seems obvious—if it’s not repeatable, it can’t be continuous—but many organizations struggle with this element. It can take several weeks or months of practice before teams start to feel comfortable with this mindset.
The increasing popularity of cloud-based computing, database, and storage resource for applications brings a whole new set of tasks to software development and deployment projects: making sure the cloud environment is properly provisioned for the software. The good news is that his process can be automated in what’s known as infrastructure automation. Infrastructure automation implements environments that have all the necessary services, frameworks, and companion software for the application to work without issues.
Among the goals of continuous development is the delivery of high-quality software that meets users’ expectations, provides a positive end-user experience, and is free of bugs and performance issues. In addition to unit testing and pre-delivery testing, continuous monitoring in the production environment is a critical element of DevOps software quality assurance. Automated monitoring tools check for performance issues and other problems and provide instant feedback to the development team.
Perhaps the most important element of a transition from iterative to continuous development is buy-in from all the stakeholders, from the organizational leadership down to the developers, testers, system administrators, and others who are impacted by the change. As mentioned previously, it takes practice to get comfortable with this new way of doing software development, and it’s easy for participants to get frustrated and fall back on the practices they’re familiar with.
Teams that successfully transition to continuous development need patience, discipline, and transparency so that issues and frustrations are addressed without finger-pointing or blaming. The transition won’t happen overnight, and there will be some stumbles along the way.
One way to smooth the transition is to enlist outside assistance. MicroStack is dedicated to educating and coaching teams making the transition to DevOps and continuous development. Contact MicroStack today to see how we can help you with your transition.