Why a deployment pipeline should be the first thing you build for your SaaS product
Recently I had a conversation with a colleague about the optimal time in the software development lifecycle to add a deployment pipeline. We agreed that ideally a pipeline should already be there by the time the dev team has the first product feature to demo to its stakeholders.
Some developers may ask “Why?”. My answer would be: for a team, having deployment pipeline from the day they start building a product, means:
- they deliver features faster,
- they have better software development culture,
- their approach to security may be more mature,
- their product may have more mature architecture.
Let’s look deeper into these benefits.
Increased Speed of Delivery
Manual routine tasks (running the test suit locally, deploying from dev machines, performing code quality checks and security scans) distract engineers from delivering features. Deployment pipeline automates routine tasks and allows developers to focus on important work to launch the MVP sooner.
Let’s look at a example to see how wasteful manual tasks can be.
If building an MVP takes 40 business days for a team of three developers, who do two 5-minute deploys per day each, then collectively they spend 40 x 3 x 2 x 5 = 1,200 minutes or 20 hours (2.5 business days) on deploys in total before the product is launched. Building a pipeline for a product at such an early stage will most likely take less time.
Better Software Development Culture
If a team is building a product with a functioning deployment pipeline, they can do (and probably are doing) Continuous Integration, Delivery and Deployment as well as other DevOps practices.
Of those three practices, Continuous Delivery is particularly important at early stage as it allows developers to demo and test the product functionality to get feedback and act on that faster.
A deployment pipeline can often be represented as code and checked into a code repository. Developers can review and version changes to such pipelines. More importantly, such pipelines documents the current deployment process and can be maintained (at least in theory) by any developer in the team, removing dependency on the engineers who originally created it.
More Mature Approach to Security
A deployment pipeline has access to the source code and production environment, so a team may have to configure appropriate roles and permissions for the pipeline and developers.
In addition to that, deployment pipeline may include steps for static code analysis, known vulnerability detection and even for pen-testing. In other words, a pipeline may be configured to demonstrate that the product has no known security vulnerabilities.
More Mature Software Architecture
In order to keep deployment pipeline short and simple, developers may prefer to use architectures optimised for deployability and testability. These two qualities have long term positive impact on software products in general.
For example, it is relatively easy to build deploy pipelines for microservices to achieve shorter deploy time and zero downtime deployments. In comparison, it may be harder to build a pipeline even for a small monolith that consists of a web UI, API, and background workers due to large number of pipeline steps types and target environments.
What would happen if a dev team delays adding a deployment pipeline to their product, some people may ask?
The answer is simple: engineers will be waisting their time on repetitive routine tasks instead of focusing on delivery, features will be taking longer to get reviewed by the stakeholders, and at least some issues in product security, architecture and software development culture will remain hidden until they start causing troubles and will get difficult to resolve. Eventually, they will add it, it will only be much harder.
I hope I’ve persuaded you to start building the MVP for your product with a deployment pipeline :)
If you found this post interesting, give some claps below or a share on social media. Thanks for reading!