Before the days of agile, scrum, and devops, software development was often done over many-month release cycles. This was largely because complexity in functional requirements, integrations, application architecture, development tools, and infrastructure made it difficult to operate faster development cycles. Even when agile development became a mainstream development process and development tools improved, organizations focused on release cycles that were on the order of several weeks to a few months.
Today, development teams that have implemented continuous integration and delivery (CI/CD) pipelines are taking steps to shorten their application release cycles. Continuous integration automates the build and kicks off test automations while continuous delivery automates code pushes and delivery processes to a targeted development or testing environment. The two processes—when managed with tools like Jenkins, TravisCI, CircleCI, Azure Pipelines, or AWS CodePipeline—automate the collaboration and plumbing that’s required for faster and more frequent application delivery.
But having CI/CD in itself is not sufficient. It also requires changes in business processes, culture, and other technical practices. Let’s look at some specifics.
Determine why shorter development cycles are needed
Going faster has some business and technical advantages. It enables faster time to market, especially where applications provide competitive value, enable significant productivity improvement, drive a happier workforce, or provide other usability improvements. It can also reduce risk when deployments have fewer changes and less likely to have unforeseen issues or dependencies. Organizations with very mature devops practices and operating in hypercompetitive areas may operationalize continuous deployments, the added practice of deploying to production multiple times per day.
But going faster comes at a cost in maturing the technical and business processes that enable driving safely at a faster speed. In addition, continuous deployment may not be the right answer for your business or application especially if they affect mission-critical workflows, operate in regulated environments, or are life-impacting technologies.
So before hitting the gas pedal harder, it’s important to ask some questions and for business and technology teams to align on motivations:
- Why go faster?
- How does going faster improve user experiences?
- How fast is fast enough?
- Can the impact of delivering more frequent releases be measured?
- What are the risks and concerns in deploying more frequently?
- What other businesses and technical practices need to speed up in parallel to support the higher velocity?
- How will the organization know whether deployments are too frequent?
Once these questions are answered, you’ll have a better gauge on what practices to focus on and what level of maturity is required.
Automate testing and security practices to improve reliability
Just because your car can go 90 miles per hour doesn’t mean that the roads are safe for driving that fast. This is true for software development as well, so both automated testing and integrated security should be part of the CI/CD pipeline to ensure releases are valid for production deployment.
To evaluate testing, consider cataloging a full list of test cases that should be automated. The list should be expansive and cover the application’s functionality, APIs, integrations, and background processes. There should also be a statistically significant volume and variety of test data that can be used to cycle through these test cases.
Once these test cases are cataloged, they can then be used as a benchmark. What percent of the catalog has automated tests? How long does it take to run through these tests?
If a high percentage of tests are automated and the cost to run them is low, that’s an indicator that they can be integrated into the CI/CD pipeline and used to validated more frequent release cycles.
For security, teams should use OWASP project principles on designing secure applications. If the application is deployed to Azure, review and implement Microsoft’s CI/CD security validation practices. Jenkins users can integrate plugins to perform penetration testing, do static code analysis, scan open source libraries, and do other vulnerability tests. If the application uses containers, implement Docker security practices, review Kubernetes security best practices, and consider these seven container security tools.
Ready operations for more frequent deployments
Even when the application is designed for faster, more frequent deployments, there is still work on the operational end to be able to support this frequency and speed.
The last thing technologists should be doing is releasing applications more frequently without a strong defense of application monitoring to detect and aid in resolving production issues. Users aren’t going to support frequent deployments if they create instability or degrade performance. Similar to automated testing, application monitors also require sufficient coverage to ensure that network operation centers (NOCs) are alerted proactively when all or parts of an application isn’t performing.
With alerts in place, IT organizations should review procedures for handling incident response. If a large percentage of incidents are being escalated to developers, increasing the release frequency may overwhelm them and cause a decrease in overall development velocity.
It’s also a good idea to review what web or mobile analytics are enabled and being used by business and technology teams. Releasing software more frequently without measuring the results and gaining insights on usage is like driving blindly. Teams should have visibility on whether their changes are providing positive impacts to users.
Define minimally viable feature sets
Teams can have all the technical practices ready for more frequent deployments, but if agile product owners are requesting complex features that require larger development efforts then it’s harder to release faster and more frequently.
In these situations, asking product owners questions about their requirements is a good start. Providing agile estimates to illustrate the complexity and timeline of the requested features can open a dialog on finding ways to simplify the requirements or roadmap the solution. Keep in mind that most product owners would rather have new features and enhancements in users’ hands faster, so providing options and new ideas may result in better solutions for users that are easier to implement.
Some development teams also look to implement feature flags, canary testing, and A/B testing to control how much new functionality becomes available, how many users get initial access, and whether new functionality is making improvements to the user experience. Having these capabilities embedded in the development process and application architecture is a highly strategic tool to validate feature design and enable more frequent release cycles.
Develop a core competency communicating application releases and changes
Development teams may not be aware of all the business processes tied to software releases. Releases that are customer facing or impacting often require communications with users on new features, changes in documentation, and sometimes executing a full marketing plan.
Enterprise application users have similar expectations and want notifications before and after releases. In addition, if the application produces data feeds or exposes APIs, internal and third-party developers that consume these services should be notified.
Organizations deploying applications frequently should consider making proactive communications a part of the business and technical processes. This is the best way to make sure users are aware and adapt to a more frequent release process.