When coding locally, a "Hello, World!" program demonstrates a functioning development environment. Deploying a minimal app to production ("Hello, Production!") demonstrates that the program runs in its intended environment. To eliminate uncertainty when deploying a new application, embrace the idea of "Hello, Production!". The earlier you get to "Hello, Production!", in the development process, the higher the return on investment (ROI). That’s because you’ll complete some one-time tasks you need to do anyway, minimizing errors and toil. For a website, this might mean a white page with the words "Hello, World!".

Here are the elements I propose every "Hello, Production!" include:

1. Remote Code Repository

2. Automated Builds

3. Automated Tests

4. Automated Deployment

5. Logging and Alerting

Remote Code Repository

Having a remote code repository, or version control, definitely helps in a team setting. However, it also helps individuals. Something could go wrong on your machine. People with cats or small children probably know best what I’m talking about. When that happens, you’ll be glad the code exists somewhere else! A remote code repository is also a prerequisite for the next two elements. As a bonus, it enables code review by others.

Automated Builds

When your code builds on a remote machine, it increases your confidence that the build is repeatable. You might have a library installed on your local machine that isn’t specified by files in your repository. When that’s the case, remote automated builds show you the problem very quickly!

Automated Tests

Automated tests run on a remote server protect your codebase from yourself (and others) when you forget to or simply don’t feel like manually running tests. On top of that, you know that your tests are reproducible. Imagine you have a local testing database with records you forgot to seed in your remote testing database. Automated tests that run on another machine surface that kind of issue right away. I find that automated testing rewards small batch sizes, because you want the tests to pass. The smaller the changes, the easier that is. In one of my favorite articles, Yes silver bullet, Mark Seemann confirms the importance of automated testing.

Automated Deployment

The importance of automatically deploying software you run yourself (as opposed to creating binaries run by others) can’t be overstated because it plays such a significant role in increasing your deployment frequency by making every deployment less effort. See this article on DORA Metrics, or even better, read Accelerate. It’s extremely valuable to find out early that the web server can’t connect to the database, or that CORS is misconfigured.

Logging and Alerting

Logging won’t come as a surprise to those familiar with the Twelve-Factor App. The point of "Hello, Production!" is to get all of the setup done so there are no impediments to rapid iteration. Seeing evidence in logs that your changes worked builds your confidence. Perhaps you are adding authorization. It’s helpful to see approval and denial logs come through.

Having alerting set up early pays dividends. It’s best to resolve the cause of all known alerts before users arrive. It’s also good to know that alerts are making it to their intended destination before users cause alerts. One thing I’ve added to web servers is a "blow up" route to make it easy to prove that alerting is properly configured. Secure it properly so it doesn’t become a vector for a denial of service attack! You can even disable or remove it after it has served its purpose.

Conclusion

Get these five elements in place before doing the rest of the development on an app:

1. Remote Code Repository

2. Automated Builds

3. Automated Tests

4. Automated Deployment

5. Logging and Alerting

By doing so, development becomes more efficient and pleasant. On your next app, don’t delay, get to "Hello, Production!" right away!