Use Continuous Deployment as an accelerator to learning serverless

When I’m working with a client development team that is new to serverless, I strongly encourage the practices of Continuous Integration (ideally through trunk-based development) and a fully automated Continuous Deployment pipeline through to production. This can often make teams a little uncomfortable as these practices are often something else that’s new to them and can seem “risky”.

While these DevOps concepts have been around for ages and are not specific in any way to serverless, they have the side-benefit of greatly accelerating learning of the serverless landscape for the developers on the team. My goal when working with a client team is to make them self-sufficient as soon as possible. And while I can point them in the way of documentation and training materials, it’s not until the rubber hits the road and they’re forced to implement and deploy features—and resolve any issues which ensue—when the real learning starts.

With serverless architectures, application developers typically have a wider responsibility than they were used to in server-based architectures. In the past, they may have been used to an Infrastructure or DevOps engineer taking their application code and deploying it to staging and production environments for them. Their job is now more than just implementing the application code in their favourite imperative programming language. This is undoubtedly a good thing given the autonomy and flow it can bring, but it does take a little getting used to.

Left alone, developers at the start of a new project may retreat to the perceived comfort of working in local branches and not merging for days or weeks. By instead introducing the healthy pressure of practising continuous integration and having their changes run through a CD pipeline, areas they don’t understand or missed are quickly flushed out. In particular, I’ve seen it really help with the following:

  • Ensuring that all cloud resources are managed via Infrastructure-as-Code and not by point-and-clicking in the AWS Console in the dev account
  • Ensuring that configuration settings—environment variables or SSM Parameter Store values—are set correctly
  • Ensuring that post-deployment integration and E2E tests have been run and no regressions have been introduced

If you’re trying to introduce serverless onto a team on a greenfield project, I strongly recommend practising CI with a fully automated Continuous Deployment pipeline. Not only will you get the generally acknowledged and statistically proven benefits of these practices, but it will also bring much accelerated learning of this new serverless world to your team.

(And if you need help putting any of this in place, there are a few different ways that I could help you, just drop me a reply.)

— Paul

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    ☎️ Serverless Clarity Call

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>