Prior to the 2010, most software companies invested in software products with a fixed up-front budget similar to purchasing a car. The desire was to "set it and forget it", designing the entire product up front and hoping to only spend small, tactical amounts of money on improving and maintaining it after this initial release. The expectations of today's customers, and the speed at which competitors are updating and improving their products, makes this approach to investing in product development dangerous in most markets. So the software industry has shifted to newer ways of designing, building, and making changes to software products. These new ways offer a more effective use of the funds available for product development in the face of today's business challenges.
What is Continuous Delivery?Most software companies create separate "environments", or "copies" of web applications that are isolated from their customers where they can make changes without disrupting them. It's common to have several of these environments dedicated to different groups of people within an organization who work together to deliver the product. For example, developers may have their own copy of a product they can make changes to. Quality assurance or "test" personnel may have their own environment. And it's common to have a "user acceptance testing" environment to inspect changes just prior to releasing them to the live or "production" environment. Pushing changes to these various environments, and coordinating the staff that use them to approve and use those changes was a custom workflow unique to every software company prior to 2010. Today a standard method has emerged that allows software teams to orchestrate the entire process of releasing changes across these environments. This method is known as Continuous Delivery, the term having been coined by Jez Humble who wrote a book of the same name in 2010 after working with many different types of companies to deliver software products.
How Continuous Delivery Changes Product DevelopmentContinuous Delivery coordinates the way staff work together, and uses deployment technologies to roll out changes to products across environments in a consistent, predictable way. Ultimately it results in more frequent, higher-quality features being released to customers - which in turn improves the efficiency of funding any software product's development.
All Content about Continuous Delivery
Many software development teams use an agile backlog but have NO business agility – and are actually using scrum with a waterfall mindset!
A story of how I tried to help a team use continuous delivery – only to see them stop following it after I left. It’s hard to hold teams accountable!
It’s always been popular to tell people how they’re “doing it wrong” and agile software development is just as easy to call “fake”.
There’s plenty of “fake news” from the software industry, so beware of the DevOps lie. In all the confusion – just follow the money to see why.
To let the customer take a larger role in deciding what’s in your product, and release it multiple times per day — you’ll have to overcome attachment.
Whether they realize it or not, many people in software development companies select processes based on their tolerance for uncertainty.
Cross functional teams get people with different disciplines to work together better when developing software.
A/B software development to find what customers value. Relying on planning up front based on customer feedback and research just isn’t competitive!
To achieve continuous delivery consider “infrastructure as code” technologies like chef, puppet, ansible, docker and the like.
The more configuration settings your application has, the more important management is so you can release your software properly.
To release software to your customers, you’ll need several development environments. They allow a team to make changes without disrupting customers.
There’s so much confusion in the market around Continuous Delivery. How does it relate to Agile Development? How does it relate to DevOps?
Your software team can avoid becoming irrelevant in today’s shifting technology market by investing in and building software differently.