Start with Continuous Deployment

When building a new product, especially in a startup, getting features in front of users for feedback is (rightly) your number one priority. However, this inevitably involves some corners being cut and the accrual of technical debt.

I’d argue (from my own experience) that teams building with serverless on AWS do in general accrue less tech debt than with other architectures. For example, serverless deployment tools force you into using Infrastructure-as-Code by default, which means it should be quicker to deploy your app to multiple environments.

Despite this, there are two particular areas which I see being commonly neglected by teams building with serverless:

1. Little or no automated integration/E2E tests
2. Not doing fully automated Continuous Deployment

The main goal of Continuous Delivery/Deployment is to enable a fast feedback loop—the exact same primary goal of the startup itself. Yet ironically, building a CI/CD pipeline is so often an afterthought, not considered until months after development. And by then, doing full-on ungated Continous Deployment seems scary, so usually a much more conservative CI-only process is established.

If you’re starting out on a new greenfield product, you have a unique window to do this. This will only get harder to do the longer you go without it.

So as soon as you have your codebase skeleton created for your new project, here’s what you can do:

1. Ensure you have hooks in place for running these different categories of tests independently: unit, integration, E2E (e.g. in the form of NPM scripts and placeholder test files).
2. Create a Continuous Delivery pipeline that deploys the latest code to multiple environments in stages running appropriate tests at different points (this article gives a good example of a pipeline I use, although I now prefer to use GitHub Actions for it all instead of AWS CodePipeline). While backend teams will have to roll their own pipeline, frontend web teams could use tools like Vercel or Netlify which provide CI/CD out of the box.
3. Practice trunk-based development instead of Gitflow or other more complex branching approaches. Trigger your main pipeline on merges to the main branch.
4. For each new feature, write integration and E2E tests to ensure they’re working as intended.

By putting all this in place at the start of the project, you are enforcing good constraints on your team that will increase quality and velocity:

• Infrastructure-as-Code and configuration management needs to be done in order for deployments to succeed. This encourages developers to become familiar with the cloud resources they’re using
• Merges to main branch will automatically go straight through to production without human intervention, so developers are incentivised to write good tests for their features
• Developers get to see their code going into production within minutes of their merge. Not only does this act as a confidence booster, but it also encourages application developers to be more conscious of operational issues such as adding appropriate alerts when building new features
• If you’re considering adding a new technology to your stack (say a framework, cloud service or third party API), you’re forced to ask important architectural questions upfront to see whether and how it will fit into your delivery workflow, e.g. does it support multiple environments, how easy it it to deploy via IaC or API, how can we test it, etc.

If you’re already somewhat down-the-road in terms of development and don’t have a CD pipeline in place, I’d recommend this free Lean Continuous Deployment Bootcamp email course by Jonathan Hall. It shows you steps you can take to incrementally move your product delivery towards Continuous Deployment, independent of whatever tech stack you’re using.