In the world of software development, there are processes followed that belong to the software development lifecycle (SDLC). Each task that is taken passes through a step. These processes ensure that the product being worked on has a clear start to finish path laid out that can be followed as it passes through different stages of its lifecycle.
DTAP which is short for Development, Testing, Acceptance, and Production outlines an approach to testing and deploying software as part of the SDLC.
These steps usually include servers where the work being done will live. Each step in development dictates how the code is moved from server to server until it is complete and made live for regular use.
Development
When work starts, most developers and programmers will have development environments set up for the work. This is where they can build and verify the work they are doing. The development server is used to test code directly by the developers and programmers. This server is usually set up with the needed hardware, software and other necessary parts for debugging and deploying finished work to test.
Test
Once work has been completed, the developers or programmers will deploy that finished work to a test server so the work can be verified. A test server’s set up and configurations will be for internal use by the team with necessary configurations so the work can be accessed for verification. This testing phase is done with the internal team, usually with the use of a QA Tester. The tester will run various use cases to ensure that the product is functioning as it should. If the tester discovers bugs or other issues, they will create tasks for the developers or programmers to look into and fix.
User Acceptance Testing (UAT)
When work passes through the internal testing phase and is considered ready for approvals, it will be deployed to a UAT server to get final client approvals before flipping the switch. The fundamental difference with a UAT and Test server is the fact that the UAT is configured to run as a production build, but the database is separate where it usually doesn’t include caching and other configurations to handle scale.
This server will be set up in an environment that the client will be using. By doing this, a client will be able to access the product on this server, use it and see a real-time view of what the product will look like and how it will function similar to how it would if it were in production. The client will be able to check that the features they requested and its dependencies are working according to their original thoughts. If the client does not like their original thought on a feature in UAT, they determine whether they want to launch as-is or change the way something is working. This can speed up approvals and limit problems that may occur after going live.
Staging
Staging is for pre-deployment. It’s like a dress rehearsal. A staging server’s set up is like production with all production configurations, and it is used to perform smoke testing to make sure the code and everything works in a production configuration and architecture. It’s the last step before production. Once everything is checked by the UI developer, backend developer, DevOps, and database administration and it’s an all-go from each, then the code is pushed to production.
Demo
Demo servers are not as common as the other servers, but in certain situations, there may be a request from a client to set up a demo server. A demo server is essentially a frozen version of a production server that is usually a few deployments behind the production. When final work is completed and approved by a client, it may be deployed to a demo server. The use of this server is primarily for showcasing the product to key stakeholders and potential or existing customers. This server will usually be used by a sales and marketing team to promote the product and allow prospects and leads to interact with the product.
Production
Production servers are the final location for all finished and approved work. When code is deployed to a production server, this means it has been approved to go live. At this stage, the work is considered complete and approved for widespread use. Working code should only be deployed to a production server after it has been tested and approved for going live. Work should never be done on a production server without the use of some type of version control as this will be a high risk for things breaking while the product is in use. In certain situations, when a product goes offline or a production server goes down, it can cost a company a lot of money and this is definitely not something anyone wants to occur.
As you can see the servers used in deploying and testing code as part of the SDLC all have different purposes and pass through certain steps. However, the end result is always to get a product live in production with as little defects as possible to ensure a fully functioning user interface and positive user experience.
Now, when it comes to Agile this type of approach tends to be contradictory to the flexibility Agile offers since this approach of switching from server to server is more like the waterfall method and can have long wait times. To make these work and still be Agile, the approach can be modified based on needs, along with the use of version control via tools such as GitHub and server deployment tools like Jenkins.
