At school, teachers usually focus on languages, algorithmic & clean code. One of the things computer science students don't learn during their studies is deployment environments. In my opinion, this is an important knowledge when starting to work for bigger companies as they tend to add more layers to their environments pipeline.
This article is more accurate and targets a certain field of people. I hope you'll find it interesting! I am eager to read your opinion on the social medias.
What is a deployment environment?
If you are here, it is probably because you are wondering what is a deployment environment (not to confuse with a development environment which is a whole other topic). An environment in the world of software deployment is « a computer system in which a program or software component is deployed and executed ». It isn't me saying this, it's Wikipedia. But this definition is pretty good, I must say.
As software systems, development processes and computer resources tend to be more distributed, they also become more complex and specialized. When working on a project, you typically go through a cycle of development, testing and release often evolving on different platforms with different resources and growing complexity. This is what we call "release management". This process allows rollout (which means "deploy something to environment"), testing and rollback if necessary (which means "remove the newly deployed version").
For the sake of understanding the rest of this post, I will briefly explain what are the different steps of product development an application usually goes through. Let me introduce you to the usual stages:
- Analyze the problem and come up with a digital solution.
- [A lot of market stuff here involving solution validation, market research, etc.]
- Design the software.
- Implement it (development of features that solve the problem and/or add more value).
- Test it.
- Deploy it (today's article is focused on this particular point)
- Maintain it / fix its bugs.
Why can deployment be difficult ?
You know that cycle I am talking about? Well it occurs from the 3rd stage to the 7th, more or less. What is important to understand in this cycle is that we usually deploy different versions of the software on different machines, at different stages of the development process and following different requirements. When you start developing an application, you already know your process management (I hope so, aha!). And in a lot of cases, you go with the Agile methodology.
Made by Tartila
I would like to point out that the cycle hides another one when you're in the industry: you have to move the different versions of your application from environments to environments. But an environment is not only a machine where your application runs! It often also means different data, different limits, different goals, different processes, and much more things with the "different" adjective. Basically, while your application is growing at a certain step (let's call it the youngest version), you have a few older versions before that need to move. If your company don't have sysadmins or that you work with the Cloud, the developer usually has to manage this rollouts and possible rollbacks (not to remind you that you don't just move the app).
While I'm pretty sure you now know how much complex it can get, let me point out that automation tools exist to ease our work (and thanks God!).
The different types of environment
Every organization has its own way of dealing with this topic, and usually it's even scoped on the project as all softwares don't rely on the same hardware & business requirements.
Let me introduce you to some of the standard environments you might encounter.
| Name | Used by | Data |
|---|---|---|
| Local | You | No client data |
| Development | Developers | No client data |
| Testing | QA engineers | No client data |
| Staging | QA engineers and/or clients | Limited production data |
| Production | End customers | Full production data |
The local environment
This is your computer. The first place where all the work happens to be done. It's broken 80% of the time.
Goals
- Work on your own tasks
- See the result and make your merry way
- Run the first battery of tests before sending your code to your colleagues
The development environment
This is the place where all developers' work lies. It is acceptable to be broken (although you should avoid it if you don't like to have your colleagues complaining about "dev being down"). Nobody but the team engaged in building the product should ever access this environment.
Goals
- Run and test with development data
- Verify that your code works well with everyone else's
The testing environment
Also called QA (for Quality Assurance), this is where the rest of your company enters the game. This environment is basically the last step before releasing the newly developed features to real end users.
Goals
- Check for any issue that previous manual and automated tests did not catch
- Prove that specific criteria are met (usually, validating the technical side of the feature)
The staging environment
This environment has a lot of names. People call it "pre-production" or even User Acceptance Testing (UAT). It is usually meant to simulate Production in as many ways as possible. It can be used to demo new features, ask for feedback from selected users validating the end to end business flow and train clients on upcoming changes.
Goals
- Prevent releasing bugs to production
- Validate end to end business flow
- Train high-touch clients on new changes
The production environment
This is the sacred environment which you should never break. Real customers are using it. If you break it, you lose money. Got it?
Goals
- Be the last depositary of all other environments.
- Give the customers the solution to their problem(s) on a specific topic
- Be reliable, bug free, always up and running
How to choose your environments pipeline?
You don't randomly choose between carved-in-stone pipelines that will answer all your needs. Pipelines are specially built for the project to be deployed. I have seen a few things here and there, and there are a lot of hosting companies like Heroku which offer help to set up your deployment pipeline.
The following figure shows a few pipelines I heard of, have been working with or am actually using. Let's say each pipeline is the default one for companies A, B & C.
Schema of companies A, B & C 's deployment pipelines
Company A
This corporation uses a well-known design called the DTAP approach standing for Development - Testing - Acceptance - Production. This is the most standard pipeline you can have. It is usually used (not as is, but largely edited) in big companies.
However, the schema for this company has a few particularities I want to talk about : the number of running instances in each environment. The schema shows that you can choose between having a single instance of your application or several ones running at a stage of the process.
Obviously, choosing to host several instances at the same time costs more and has its cons but brings a few advantages :
- You can deploy specific features on a specific instance.
- It allows your development team to work in smaller groups (e.g.: team 1 works on list 1 of features in instance 1; team 2 on list 2 in instance 2; ...).
- It's cool to see when your instance runs smoothly and the others are down because they fucked up (don't get blind though, you'll get by that damn road as well).
Company B & Company C
These companies got rid of the "test" environment. This happens when you can afford to test your flow along with everything else in either your development environment or your staging environment. It is also a possibility for small teams.
The only difference between these two are the number of instances running at each stage. When building a small project, you usually go for company C's plan as there are less steps to do in order to deploy and go from one environment to another.
In my humble opinion, I like the schema C but I'd rather simplify it again. For example, when I work on a Discord bot (if you don't know Discord, check it out), I use :
- my local environment running locally and connecting to Cloud resources (such as a database and Discord's web service),
- the dev/staging environment (yep, it's a single env) running the beta version of the bot, and
- the production environment which hosts the final version of the bot available for Discord users.
I cannot give you some sacred deployment approach dipped in magic sauce that will perfectly work for all your projects because it does not exist. You must come up with your own custom plan. But these defaults should at least guide you for a bit!
And you guys, what does your favorite deployment pipeline look like?
Conclusion
Deployment environments are a big story and this article only has the purpose to gently half-open a door. As the DevOps trend is more and more intriguing in the eyes of companies, it is a plus to have experience with such things.
I hope you will fully open the doors I wish to show you. Until then, see you next time!