You’ve written an application and it just hit 1.0. Now what? An application that hasn’t been deployed is just some text up in GitHub. What is involved in deploying an application? For small, personal projects it may be fine to throw it on a server and walk away, but in a professional environment things are much different. Whether it’s a developed application or a third party service you need to deploy in your infrastructure, there are a few points to take into consideration.

System Requirements

The first question is, where is it going to live, and what are the requirements for running it? For third party services, usually this is well defined in documentation. Otherwise, there needs to be some benchmarking performed in development to determine the requirements. A few points to keep in mind:

• What are the storage requirements?
• What monitoring will be required?
• What are the extra packages required?
• What files are used at runtime, and what does retention look like (for example, log files)?
• What ports are needed, and how does that need to link into the network?

CICD

Continuous integration is important, and will likely already be setup for a service by the time it is ready to be deployed, but it is easy to overlook some tests in the development process. Applications need more than test coverage and lint, security scanning is also important. If an artifact needs to be made (such as a container or an RPM), then that process needs to be setup. A formalized process to determine how code is integrated into a release needs to be specified, and permissions checked so that only trusted code owners can release code to production

Another thing to keep in mind is how the service is deployed. There are many choices, like deploying to a VM on a cloud provider, creating a container, or just throwing the service directly on to a bare metal server. Whatever the case, the deployment should be automated, and include all tertiary mecehanisms like service discovery, monitoring, and logging. Incident response should be baked in as well, when monitoring detects a production issue, a real person needs to be paged.

There should only be one purpose to the server it is deployed to. The single responsibility principle applies to infrastructure too, one server should have one service and one defined purpose.

Who Owns It?

This is probably the biggest question to ask. For a team that developed an application, it is more obivious. For a third party service or services created in house by individual members, the ownership might be more ambiguous. I’ll admit that I’ve done this before. Sometimes there are a lot of problems to solve, and it is easy to jump in and solve it, but the business as a whole should decide whether to proceed with a solution. One person cannot effectively own a service, what if they leave, or something horrible happens to them? The business as a whole should determine an owning team for the service that has the skillset to manage the service.