Basic Automation: Feature stages

Today, I want to talk about something that I believe every web development team of a certain size should have: feature staging branches.

At Techgenosse eG, where we work asynchronously with our customers and often handle multiple features at once, we ran into a common issue. Our staging server often didn’t have the most relevant feature-branch deployed during the QA phase.

This meant we’d often receive requests during QA to deploy a specific feature to staging.

Initially, we tried to solve this by adding a button in GitLab that allowed the QA person to deploy any branch to staging themselves.

However, this solution wasn’t ideal. First, deployments take time. Time that could be used to test a feature. Even though it freed up the developers, we realized QA shouldn’t have to deploy things themselves. Additionally, we frequently needed to show customers new features or test things in an environment closer to production, which wasn’t always possible in our dev setup.

That’s when we came up with the simple but effective idea of feature stages.

We have one main staging-site main.stage.project.example.com, that always contains the main branch.

Whenever a developer commits, we clone the database, files, and feature flags from the main instance to create a new featurebranch.stage.project.example.com instance.

This approach has several key benefits:

• No more manual deployments
• Every branch can be previewed and tested by QA at any time, creating more transparency and speed
• Developers can use staging to check how things would perform in production
• We can show customers new features easily

We’ve implemented feature stages for many of our customers. Whether using Capistrano, shell scripts, Ansible, or Kubernetes, it’s always been relatively simple to set them up, if deployment is already automated. The best part is that everyone quickly accepted it and loved it, saving countless man-hours.

So, do you already have feature stages in your workflow?