Releases should be done frequently and not when people are about to go home for the day. Frequent releases mean small releases. That means if something goes wrong, it’s not painful to roll back. With orgs that do giant releases, they generally do a big release, and then hold a war room to catch the fallout. When you have several applications each with several features and fixes, you’ve introduced so many variables that it’s nearly impossible to narrow down the culprit in a timely fashion when your app is broken in the sacred production environment. Any integration point requires people from multiple teams - I’ve even seen where an integration between two apps pulls in people from 3-4 teams because two teams stand in the middle of the apps (usually operations and security). This is a colossal waste of resources and very damaging to your team’s morale. If someone deploys a new button and the button screws up your page layout, reverting is a no brainer.

You can use flags (generally configuration variables) in your codebase to disable or enable certain features. Take the button out entirely and only enable it when you want to. This makes it easy to deploy changes all the way to production because your code when deployed shouldn’t do anything until you actually flip the switch. This is

Your app might have a suite of unit test, acceptance tests, type checks, etc that can be run. You want to run all of these. On my teams I put in checks for formatting as well.

Software engineer salaries are pretty high, and costs for hardware or hosting is very low. Having an environment where your software gets automatically deployed on any successful build is essential.

You need environments. An environment is a place where the software lives. This might be a server where your web app gets deployed. It also accounts for other apps that need to live alongside your primary app. Getting environments going needs to be cheap. You should have scripts to define your environment. If your environment setup is just “our server person hammered on it until it worked” then you’re going to have all kinds of variance between your environments that’s subtle and impossible to account for. You will invite disaster in your deployment process. Script it, and have the scripts take variables on what environment the setup occurs.

Let’s cover some environments and how you’d use them:

local

This is your local environment, or what you do to iterate quickly on your machine. I’ve seen some places that don’t actually have a local environment. You just edit in a develop server that might or might not be shared by other engineers. This is bad. Having your engineer be able to work from anywhere is valuable. Connection issues should not hamper your development process. That means you need to be able to run as much as possible locally and test as much as possible locally.

develop

(Or dev) is an environment with a singular purpose: It demonstrates that the software can run when it’s not in the local environment. I recommend develop continues to run with whatever mocks you have. Your CI/CD setup should automatically deploy to this environment once you successfully automatically test and build the software. You can use it as a “here’s what’s current” place as well. I would let QA know about this environment, but create the expectation that there’s a proverbial gun pointed at it. The data that exists there, and any running processes are forfeit no a whim.

integration

This like develop except it interfaces with real external tooling. If your app needs to talk to another app, this is the environment where it actually happens. If you’re in a large org with lots of apps, this is where all of them can meet. Lots of shops like to gate deployment here - meaning some human has to hit a button to make what’s in develop is deployed to integration. This is not a great idea. The problem gating an integration deployment is trying to solve is that if someone else relies on your software working a certain way, then your cutting-edge deployments will break their stuff. Breaking here is a good thing. We need to be able to enable or disable functionality using feature flags, or use versioned API calls to prevent backwards incompatible changes from breaking our consumers. Automated deploys to integration allow us to catch those. The whole point of this environment is that we find out what’s breaking when we connect everything together. If this hampers your consumers’ development process, then have a discussion about how to mock whatever it is they are consuming.

staging

This is QA’s test bed. It should be gated. The reason being is that QA needs to be able to test things without the test subject being ripped out from under them. That said, it’s not an excuse to allow staging to drift far behind of what develop is. The larger the delta in changes, the more painful it will be to fix any problems that got deployed.

production

AKA prod. This is where our end users consume our software. This place is sacred ground and changes made to this environment should be made with extreme caution. Deployment should be gated here, but realistically speaking you could have multiple production deployments per day. Any time QA approves a software change in staging we should do a deployment to production.

Lots of places require release notes to be present as part of a release. Release notes, or a change log is a list of what’s different about this particular version of the software. For some reason this is one of the easier things to automate that we generally fail to automate. Be lazy. Let the computer do the work for you. It’s better at it than you are anyways.

Here’s an example of what release notes might look like:

My Shiny App v1.1.2

1. Fixed issue #12344 :: Clicking buttons no longer mocks you for clicking them
                        out of order.
2. Fixed issue #15532 :: The app no longer crashes when you try to do useful
                        things in it.
3. New Feature :: You can now add stickers to your reviews even if it adds no
                  inherent value to your reviews. I just know this is what they
                  did in SnapChat and they are worth bazillions okay?

But if you’re a mobile developer you’ll get a free pass:

Bugfixes and performance enhancements.

See how far something like that will go on your résumé.

Let’s just assume that we want to write quality software for a moment and show some intention behind the changes we make. If we must add the ability to hold the thumb button to make the thumbs up icon bigger, at least we’ll know it got in there on purpose.