Using Declarative Continuous Deployment Pipelines
Pavan Belagatti explains why he's in favor of using third-party Continuous Deployment pipelines instead of homegrown ones. Do you agree with him?
Join the DZone community and get the full member experience.Join For Free
Continuous Deployment is the key for every software-powered organization to increase overall productivity and make things move quickly. The motto is to automate repetitive tasks as much as possible, so that, the team can focus more on the product, developing the core features for the end user.
However, many of you might argue to have a homegrown CD pipelines but Continuous Deployment (CD) today is synonymous with fragile homegrown solutions made of disjointed tools cobbled together with thousands of lines of imperative scripts which is hard to create, maintain and many of the organizations cannot afford it.
Continuous Deployment always aims at innovation and platforms like shippable have all the integrations and support for your organization from running unit tests to production and ultimately deployment.
Most organizations today are at L1 or L2 of this maturity model, i.e., they have a CI server that runs unit tests and packaging for every code commit. Some have the capability to deploy to one endpoint as part of their CI. However, this does not address the flow of that service or application through various test environments and ultimately to production.
In this video, Avi Cavale, Co-Founder and CEO at Shippable, walks you through the CD maturity model and demos an end-to-end Continuous Deployment with declarative pipelines for Docker applications. Here's a rundown of it.
Advantages of Practicing Continuous Deployment
Dev teams should eliminate DIY for CD and focus on the product. This can be done by leveraging declarative YML-based constructs and not building imperative scripts, configuring and managing entire pipelines from Git, and visualizing application dependency graphs in a single pane of glass.
Test teams should automate repetitive tasks and focus on testing. This can be done by provisioning and destroying test environments on-demand, automatically firing test suites on code commits to isolate each problem to a single SHA, and managing product versions as part of the workflow and creating quality gates for automated product releases.
Ops teams should make deployments frictionless without compromising security. This can be done by centralizing the management of configurations, security patches and access control across environments, tracking and auditing all changes made to production all the way back to source control, and using no-touch deployments and auto-scaling of applications in production.
Homegrown Continuous Deployment pipelines are prone to errors and creating them takes a lot of time. There's also a lot of money involved in spinning up servers and other supported objects. So, going for a third-party platform that does the work for you may be better. Doing so saves time that you can invest in analyzing your product and making plans for your next release.
Published at DZone with permission of Pavan Belagatti, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Mastering Time Series Analysis: Techniques, Models, and Strategies
Merge GraphQL Schemas Using Apollo Server and Koa
Revolutionizing Algorithmic Trading: The Power of Reinforcement Learning
SRE vs. DevOps