Image for post
Image for post

At Capmo, we are currently evaluating to move our entire backend stack to Nest.js because of its many benefits (which I won’t mention in this blog post as there are plenty of others on that matter).

Since we already have a legacy application running in production, we unfortunately are not looking at a green field here but need to move building blocks piece by piece — among others we have some serverless micro-services that are built using AWS Lambda which we also want to migrate and extend to keep a consistent structure and experience across our backend stack. Those services mainly use native AWS integrations via API Gateway, S3 events or SQS triggers. While there is material on the Internet on how to integrate Nest.js with API Gateway (e.g. here), most approaches rely on a proxy integration between API Gateway and a (cached) express.js or fastify instance. There are ways to interface with other cloud-native integrations using Nest.js


Image for post
Image for post

At Capmo we are continuously searching for new ways to improve our product development process to be more agile, inclusive and to support different work modes, sync as well as async. This article describes how we tackled a particular problem we encountered as soon as we had more than one person on the team working on our web application — the problem of design and product management not being able to give feedback on multiple increments being worked on in parallel early in the process when having a limited amount of environments to deploy to.

Our starting point

We started off having three separate environments for our web application, development, staging and production. This is a fairly standard setup as seen in many teams. We used to merge commits for new increments directly to our development branch which was directly tied to our development environment — every commit would trigger an immediate deployment (we use CircleCI for that). This setup works well as long as the team is small, working synchronously and closely together. As we grew, and we got more than one person on the team working on work items in parallel, we noticed certain drawbacks: our development environment started to become a digital version of the wild west, multiple things being crumbled together, leading to confusion, broken deployments and reduced clarity. We found ourselves continuously overwriting things as we go and a certain communication overhead coming with that. After all, we needed new code running somewhere such that PMs and designers could check out and review new things as they were built, without the need of standing next to an engineer’s computer while they present their work. At this point we started discussing about switching to gitflow as our primary workflow for development, yet we weren’t quite satisfied with the added complexity it brings to our otherwise nice and simple workflow — having master tied to staging and production and having a single branch per feature/task/bug. Plus, this wouldn’t actually have solved our problem to a degree we would have been satisfied, as new increments ending up on the development branch would be likewise hard to review and prone to get messy. Please note here that we try to ship as early and as fast to production as possible (using feature toggles), hence introducing some lengthy review cycles we didn’t like either. …

Sebastian Schlecht

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store