Organizations large and small are struggling to meet their Key Performance Indicator (KPI) goals and prevent IT issues before they adversely impact the business — in fact, organizations detect and address an average of only 57% of critical IT issues before they impact the business — according to Continuity Software's 2015 IT Operations Analytics Survey ...
Continuous delivery, continuous deployment and continuous integration — what do these all mean and are they the same thing, or even related? There is a lot of confusion around continuous delivery, but what isn't a mystery is that this topic and manner of releasing applications into production is a hot button issue in the industry right now.
Continuous delivery is defined as releasing into production high quality software quickly, through build, test and deployment automation. Basically the process allows organizations to release software into the “wild” in minutes, opposed to days or even weeks.
Test automation is the sticky point for many organizations opposed to continuous delivery — yes, we said opposed. Similar to how many IT organizations balked at adopting Agile development at first, organizations are doing the same for continuous delivery. The reason: it is a relatively new paradigm shift to traditional software deployment. The controversy: there is much less emphasis on the testing phase of the process than with more traditional software development and release.
What everyone can agree on is the driving force behind continuous delivery: the speed that software can be delivered into production is unmatched compared to traditional software release trains.
DevOps, Continuous Integration and Lean Computing
There are three aspects that make up continuous delivery: DevOps, continuous integration and lean computing – tying these together is when the magic happens.
The DevOps community focuses on infrastructure as code, monitoring and improved collaboration between the houses of development, test and operations.
Lean is about innovating efficiently, soliciting feedback from customers as quickly as possible and leveraging technical competences such as continuous integration, comprehensive configuration management, automation of build, test, provision and deploy processes.
Like any continuous improvement, it should be achieved incrementally, taking into account where folks are starting from and their ability to effect changes and adopt them. The tools, practices and patterns are now available to support this, and Serena uniquely orchestrates enterprise agility.
Incidentally the KPI or metric we should be measuring is the cycle time for the software delivery process (implies a continuous delivery workflow).
For continuous integration, there is a significant cost savings to consider. Since Continuous Integration is in the early development cycle, many changes are tested frequently with feedback immediately going the development team. Multiple changes from multiple developers are developed and tested with many deployments daily.
The earlier in the development, test and release cycle that a problem is identified and a fix developed, the lower the cost. It is much more expensive to fix problems after the application is in late-stage testing, pre-production, or production. Therefore, effective continuous integration reduces costs and reduces risks.
Today’s successful business is lean, efficient and lives online. It is an agile enterprise, relying on non-traditional IT imperatives such as Cloud, mobile and social computing. These companies are defined by the new and enhanced solutions empowering their IT stakeholders. From operating on mobile phones and tablets, to automating the release of their applications both on-premises and to the Cloud, agile enterprises live and breathe efficiency. Continuous deployment delivers the speed and agility these companies crave. They do not have time to wait for three-month development and release cycles they need software deployed in minutes.
While there is an interesting angle around APM and measuring performance, adoption, etc. once deployed as an ex development manager, there is still much improvement available in the area of test automation and in particular the adoption of TDD (Test Driven Development) practices.
We have come up with the five steps organizations can take to optimize continuous delivery:
Step 1: Make the release management process and workflow accessible for many different IT functions through a common function portal for: Business, Development, Test/QA, DevOps, Release, IT Operations and IT Service Management.
Step 2: Document detailed requirements in demand, stories and the requirements management process.
Step 3: Connect the requirements, development, and release processes. Ensure that the only changes that are released are those that have been defined by requirements management and approved by the business.
Step 4: Orchestrate the release management process with Development so that newly developed code from multiple development environments flows smoothly into the common release management process.
Step 5: Improve release management flexibility through improved support of:
- Traditional Stage-Gate QA methodology
- Modern Continuous Delivery QA methodology
- Support for many different environments for deployments (test, SIT, UAT, Staging, Pre-Prod, Production)
- Support for multiple platforms such as, Windows, Linux, Unix, Mainframe
For companies that want to take this developer-driven approach, there has to be an understanding of the changes required in getting to continuous delivery and how it affects the whole process for getting new software and updates out to the organization.
The benefit of going down this route is that IT as a whole can be more nimble in responding to a changing market, whether this is launching new services or expanding available functionality. With a lot more businesses looking at how to expand the ethos of agile from development into their wider organization, this is a great opportunity to show the rest of the world how things can and should be done.
ABOUT Ashley Owen
Ashley (Ash) Owen is Serena Software’s Director of Orchestrated ALM Strategy for the ALM Business, providing product management assistance, field support and solution strategy & advice to our customers, prospects and partners. Extensive experience in the successful design and implementation of ALM solutions across Europe, APAC and America.
Ash has spent more than 23 years in Application Lifecycle Management and Software Change and Configuration Management markets. Ash has a singular focus on improving efficiency, automation and traceability within both Enterprise IT and Embedded Systems environments.