Environments¶

Our development process considers four different code phases:

1. Development when we start working on tasks or issues.
2. Testing when our qa team run their test cases batteries on well defined releases.
3. User acceptance when our customer tries the next release to check if what he is going to receive sticks to our commitments and their needs.
4. Production when it's being used by final users.

The process might sound a little bit cumbersome and slow but it actually doesn't need to be like that. We should be able to push and move releases through those different steps every sprint. Moving fast doesn't mean we need to not to take care about quality and delivering really good software therefore such steps exist.

One important thing to consider when sticking to that workflow is that different environment are going to be used to guarantee data isolation (i.e. avoid stepping each other's toes). The following environments are defined:

• QA / Staging:

  • It will be used by QA team to approve (or not) the next release.
  • It can also be used by DEV and QA teams to try to reproduce a production bug if necessary.
  • The team might use or set predefined data so this environment should not be used without their approval. For example consider a functionality that displays some kind of statistic about operations being made on the system. They will probably setup or run some steps to generate some data and compare if what they see on screen matches their expectations. If someone else (a developer, a PM, etc) uses the system at the same time the test might not pass even if the release is just fine. Even if that case could be detected it doesn't stick to their scenarios.
  • This environment is owned by QA therefore they decide when is ok to deploy to it.
  • As this server might contain several issues or bugs (we should try to minimize such events but that's why QA is there in the first place) it should only be accessed by Atix team members.

• UAT:

  • It will be accessed and used by some specific people designated by our customer to either approve or reject a deploy.
  • The same concept as QA applies to this environment. The users that will accept the release are the owners, ie, it must be agreed with them about when is it ok to deploy.
  • Nothing but releases approved by QA can be deployed to this environment. Remember we are looking for users approval so everything should have been approved by the QA team just to guarantee we will be delivering what has been requested and their tests will work.

• Production

  • Regardless the owner of the servers (sometimes we provide production operations service for our customers), the owner of this environment is our customer. When, how and what to deploy must be agreed and accepted by them.