https://www.techtarget.com/searchitoperations/tip/Top-continuous-delivery-benefits-and-how-to-get-them
Traditional software development paradigms take months or even years while the team gathers requirements, architects, builds, tests and releases a product. Then, it starts the cycle again for improvements. It's a risky investment. The principal means to mitigate software development's risks is to accelerate this cycle.
Continuous delivery, especially combined with continuous integration for CI/CD, approaches development in short build, test and release cycles. The goal is typically to create the product in an iterative exercise rather than with an endpoint. Each cycle fixes prior flaws, refines performance and brings new features and functionality to the product.
The continuous delivery pipeline might be the domain of software developers and IT engineers, but its positive consequences for the business should be broadly communicated to encourage buy-in throughout the organization.
Requirements are the suite of features and functions that the business predicts its users want. Unfortunately, they rarely get it 100% right and only discover that after considerable resources went into creating features and functions.
Developers can obtain rapid feedback from each release cycle in continuous delivery, which leads to a far more dynamic picture of the useful features and any challenges with them. Developers better understand and refine the product's most useful features and can ignore and depreciate the least useful ones. When done right, continuous delivery benefits include a more mature and competitive software product.
Testing reveals many software flaws, but bugs can slip through a traditional test phase and into a major release. While developers generally prioritize bug remediation, users must grapple with those flaws until an appropriate patch is prepared -- a post-release process that can take weeks or even months. The damage is done.
By comparison, faster, smaller release cycles generally mean less code to break.
CD means code releases receive rapid feedback that reveals software flaws and performance issues. A new cycle follows not long after, giving developers the opportunity to roll out a fix.
Businesses are risk-averse. When a new product takes years, failure is simply not an option. This harsh reality tends to stifle innovation on new, unproven features or functions.
Shorter iterations enabled by CD reduce the risk of each release. When a CD cycle that took days, or even just several hours, results in a failed experiment or unintended consequences, these problems can be readily fixed, refined, optimized or even removed with subsequent release cycles. The potential benefits of innovation now outweigh the risks of failure.
Businesses constantly vie for revenue and market share. They must develop and release the best software ahead of the competition. Not only does traditional software development need longer than iterative development to design, build, test and release a product, it is ill-equipped to deal with a shift in user needs and expectations.
CD follows a far more aggressive schedule and is broken up into smaller releases. A business can bring capabilities, especially newly developed or innovative ones, to market much sooner than traditional development models allow.
CD can also dramatically improve IT operations processes. Traditional release cycles are infrequent, which causes a lack of expertise in actual physical deployments. Operations teams deal with time-consuming software deployment errors and troubleshooting.
With CD, frequent deployment of new software iterations is impossible with Ad hoc or uncertain IT processes. IT must implement stable, reliable and less risky deployment and rollback practices, establishing what works well and what does not.
Traditional development and testing environments are provisioned manually by an IT or infrastructure team. Continuous delivery cannot function with this cumbersome and time-consuming process. It requires extensive scripting and automation to create and tear down development, testing and deployment environments. Automation saves significant time, reduces troubleshooting and ensures consistency. When done right, it means IT spends less time supporting the deployment environment.
Adopt a CD tool set that can organize and shepherd a project cycle from inception to deployment. There is no one, single toolchain for CD, nor is one toolchain guaranteed to produce all of the listed continuous delivery benefits.
Each organization should build a toolchain that accommodates its business needs and the needs of development teams. Encourage developers, database admins, testers, security teams and IT operations to use these tools in a pipeline:
Continuous delivery benefits are not automatic or guaranteed. Follow these best practices to ingrain CI/CD processes into software delivery.
Even the best and most comprehensive tools fall flat without a well-conceived and refined process. Automation plays a crucial role in CD. Establish a clear, repeatable process in order to invoke a CI/CD cycle, and make sure that process reflects automated mechanisms within the tools. Expect to focus on integrations, where the output of one tool provides a suitable input for the next tool in the chain, configuration files, scripts and more.
Eliminate traditional processes that impede rapid development and release. For example, the change advisory board of developers and business leaders who review and approve each update or revision is unsuitable for rapid release cycles. Encourage collaborative development and operations teams. There must be a fundamental willingness to deliver rapid, iterative code and eliminate delays.
Some projects are better suited to continuous delivery than others. Implement CI/CD on software products that demand the fastest time to market and can tolerate high levels of disruption and change. The benefits are less defined for mission-critical enterprise applications that demand low disruption and high predictability. CD and other development paradigms are not mutually exclusive, and different teams can choose the one that best suits the project at hand.
01 Aug 2018