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

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

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

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

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!

Software engineer, manager since 2002. Engineering management, leadership, software architecture, high-performing teams, professional growth.

Software engineer, manager since 2002. Engineering management, leadership, software architecture, high-performing teams, professional growth.