What and what are the types of development environment?

Question

Occasionally I see something like this in several projects:

env: 'production'

What is this? What are the other conventional options (besides "Production") and what is it for?

Why should I use this in my application?

Answer 1

Usually you find at least 2 development environments:

• development
• producing

Depending on the creativity and bureaucracy involved in the process, you can have other environments:

• development
• test (*)
• homologation
• beta
• producing

(*): here highlighting the test and separating from the development, because often the development environment the programmer himself addicted him. It can be by placing artificial data to proceed with the task or normalizing wild data for behaved and controlled data. The test environment in this case is the responsibility of the testing/quality/QA sector, which keeps the data as close as possible to the production savagery (or forces it to a specific type of savagery to test some aspect).

I will focus on the rest of the answer only on the most notorious division: development and production.

Why separate?

So that the developer can break it. No fear. So that it’s his litter box and he can do whatever he wants or needs without worrying about consequences.

The production environment is a sensitive place. It is usually said that "no test is done in production", and this phrase is true almost always.

In my case, I work with a sales system. To make some change the customer asked to add some rule of sale, I need to conduct a sale. I can do much of what I want and test these changes and not save the sale order at the last minute. But it is not always possible.

Imagine the following scenario:

• i need the order to be pending for customers who are behind; each group of customers will have a different delay limit.

I can only guarantee that the order for the "good payer" group customer who is late to 90 days will be pending if I place the order, save and check. Now, imagine that I am still developing the system and for a bug the request was not pending. This means that this order will automatically be processed and issued to the customer. When the order arrives at the customer’s door, he will say that he has not made this request and will send back.

In addition to the inconvenience of the return freight of the goods, I will still have caused an unnecessary stress between the seller and the customer. In the test environment, this request would not be processed, even by bug. Therefore, it would never stop at his port. I would not have stress for anyone and I can develop quietly without worrying if I will cause harm to someone (besides any delays in deliveries).

Another situation that could happen, too, and that would generate headaches. Imagine that you decided to change the system infrastructure to use a ORM, which needed to do this to give greater maintainability in the system. You initially applied the most naive form of this, and you didn’t realize that you were checking which objects within 1,000,000 related to another 1,000,000 objects, so the system had to test all the possibilities to mount the mapping. You can see that this possible mapping occupies more than 10 billion items (it actually occupies 10 12, a trillion items). And you did all of this, for each separate mapping of this trillion, by making a query at the bank. Your database would have to handle 1 trillion queries, which is much. If your bank is very good and at 100% capacity meet 1 billion requests per second, it would still be necessary to wait about 20 minutes until it is available to those who use it in production. You unintentionally made a denial-of-service attack on your server, and your users didn’t understand for a third of an hour what was actually happening.

When should I use these environments?

If you are developing something, then it is a sign that you should select the "development" environment. This should be obvious.

If you have already closed your product and are delivering it to the customer, then select which one is in production.

If you use other environments (like the five-environment scale I mentioned), then the person responsible for putting these things on the air knows which environment to use in each situation.

Whose responsibility it is to set this up?

This responsibility lies with the "operations" sector. Developers should not touch it (except to "test in production", and this should be done with all the affection in the world). The developer should put for development and forget about the existence of this in... almost all cases that do not involve bugs?

Of course, the Devops philosophy is to bring development and production closer together. But it’s good to separate who is who. For example, the Jefferson developer likes to explore and try algorithms and innovative techniques to solve his problems, but the Jefferson of operations likes things to have a more gradual and controlled evolution, more guaranteed and safe. The internal conflict between my two Jeffersons makes me try to make a balanced decision.

The Jefferson developer is more stubborn and usually wins

He always presents separation this way?

No, it’s not always like this. Where I work, we have the files jdbc-dev.properties, jdbc-prod.properties. Somewhere in the addition of dependencies is pointed out which of these database settings is actually used at that time, pointing to the file name.

Should I use in my application?

Maybe. Probably. For the reasons mentioned above. Now, know that this is a bureaucracy, that it increases the security of development at the expense of some speed (possibly). So, if you’re doing this just to develop your portfolio, or just to study, I don’t know if it’s worth spending a little time with.