The Serverless 12-Factor App No. 5: Build, Release, Run

Stackery sponsored this post.

This series of articles explores what we need to do to follow the design requirements of a 12-Factor App for ease of development and maintainability. Check back each week for future installments.

The 12-factor app is one that is easy to maintain and, more critically, is fun to work on.

Fun?

Yup — as a coder, the pleasure from doing the work largely comes from releasing working code. A successful 12-factor app is one that makes it easy to release code frequently that works in production the first time.

The fifth factor in the 12-factor model is about the separation of concerns and phases for the development of your app.

V. Build, Release, Run: Strictly Separate Build and Run Stages

Toby Fee

Toby is a community developer at Stackery. Her roles and experience combine working as a software engineer, writer and technology instructor, building interesting projects with emerging tools and sharing her findings with the world. Prior to joining Stackery, Toby was an engineer at NWEA, Vacasa and New Relic.

Like some of the previous requirements, this is one that it’s relatively difficult to screw up, but it isn’t implicit in using something like the Amazon Web Service (AWS) console to deploy your serverless function (Lambda).

Runtime changes are totally meaningless with serverless — your code starts whenever it’s needed and not otherwise. You thus don’t manage starts or shutdown (or restarts), so there’s nothing special you can do at runtime to make your code work. We only really need to worry about Build and Release, since those phases are the ones that require human oversight!

When you’re just copy-pasting code into the Lambda dashboard, the separation of Build and Release phases aren’t that distinct. Build isn’t a particularly meaningful concept for a NodeJS app, but even with other languages, there doesn’t feel like any separate “build phase.”

However, if you use AWS CloudFormation, you’re explicitly separating the build phase — to run a CloudFormation deploy you’re “releasing” code at a point that can be meaningfully regressed to and explored.

But There Is a Problem

This brings us to a problem that isn’t listed in the 12-factor model but definitely affects serverless: during the pre-build phase during development, you shouldn’t need to perform a full release just to see your code work.

The “develop” phase is undertaken before anything covered by this principle. However, it’s implicit that you shouldn’t need to do the other three to see your code work the first time.

This isn’t part of the 12-factor design principles because before serverless this would have been a “well, duh” thing. Of course, you need to be able to hack on application code. Of course, you need a “development” environment that comes before staging and before testing.

Okay, why is this a problem with serverless? It’s because serverless requires more than just functions, so to see your function really work, you need them to run within the cloud

This has led to some muddling between the development and release steps, with devs doing full deploys (and waiting 10 minutes!) to see their code work at all.

To get some insight into this problem, see a high-level overview from Nate Taggart, and Sam Goldstein with an exploration of the developer work loop on the Stackery blog.

Feature image via Pixabay.

Nica Fee helps teams adopt serverless and optimize their costs on AWS. She is a Serverless Developer Advocate for New Relic.

Read more from Nočnica Fee