Share Deployment Best Practices to Create a Better Process

ISVs should share their knowledge and experience to shape a more efficient process that improves workflow, development velocity and product quality.

technology-enterprise

Application deployment has evolved immensely in the last few years. The DevOps community has iterated the process extensively to create complex tech stacks and execution steps with many different approaches. That’s why developers should share their knowledge and experience to shape a more efficient process that improves workflow, development velocity and product quality.

The DevOps community is very collaborative, but our focus is often on our software development. One team may adopt an inventive deployment improvement but may not share the approach with others because of the team’s many responsibilities. When teams work in silos, they formulate individual strategies. Those varied processes create different innovation rates, making business forecasting a challenge. A collaborative approach reduces complexity because developers aren’t creating new solutions when effective ones already exist.

How can developers effectively share best practices? By adopting continuous deployment.

How continuous deployment enables best practices

Continuous deployment is a declarative approach that makes software delivery simple, predictable, repeatable and reliable. Reliability is the top priority for more than 80% of organizations. Continuous deployment follows continuous integration and delivery by automatically pushing code into production and checking its health. The process ensures all software updates follow the same validation logic.

Automated Canary analysis — a progressive rollout approach that gradually expands the audience receiving the update — is an excellent strategy to limit new code’s blast radius, but many teams are too focused on deployment tasks to tackle the more complex process. Continuous deployment can help by automating the steps, monitoring for problems and moving the code to the next stage without human intervention. If a problem arises, rollback is easy. Even pre-elite teams can successfully use progressive deployment.

No need for a self-built tool

Developers have done the work of simplifying deployment, so take advantage. Developing your own deployment tool may seem cost-effective, but it limits performance in the long run. With the self-built approach, teams often focus on a basic checklist rather than the bigger picture of improving performance metrics. Additionally, a proprietary solution does not scale to accommodate increasing demand, complexity and expectations. Teams find themselves constantly updating and troubleshooting rather than focusing on their code.

Tools already exist to enable deployment. By investing in an existing solution, developers and engineers can spend their time on value-driven activities like building software rather than the tedious tasks involved in deployment and DIY tool maintenance. There’s no need to find your own solution. Others have already done the work — leverage those practices to maximize time and resources.

Let’s be honest — developers compete to create the best software, not the best deployment process. Gatekeeping inhibits innovation. By sharing best practices, we can work together to improve and simplify deployment.

Andrew Backes

Andrew Backes is the VP of Engineering at Armory and was the first employee at the company. Over the last six years, he’s established the Armory platform as a reliable software delivery platform for enterprises and built a world-class engineering team. He was previously an engineer at @ShareThis, where he worked on Big Data and built internal development tools. Before that, he ran his own IT consulting business.


Zebra MC9400
Andrew Backes

Andrew Backes is the VP of Engineering at Armory and was the first employee at the company. Over the last six years, he’s established the Armory platform as a reliable software delivery platform for enterprises and built a world-class engineering team. He was previously an engineer at @ShareThis, where he worked on Big Data and built internal development tools. Before that, he ran his own IT consulting business.