The Software Development Lifecycle
In software development, developers follow processes that belong to the software development lifecycle (SDLC). Each task that someone takes passes through a step of the process. These processes ensure that the product you are working on has a clear start-to-finish path. You will follow this path as your product passes through different stages of its lifecycle.
DTAP (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 will live. Each step in development dictates how you move the code between servers until it is complete and made life.
Development
When work starts, most developers and programmers will have development environments set up for the job. This is where they can build and verify the work they are doing. Developers and programmers use the development server to test code directly. This server usually has the hardware, software, and other necessary parts for debugging and deploying.
Test
Once the developers or programmers complete the work, they will deploy that finished work to a test server. A test server’s setup and configurations will be for internal use by the team with the necessary arrangements. This allows the team to access the work for verification. The internal team completes the testing phase, usually using a QA Tester. The tester will run various use cases to ensure the product functions as it should. If the tester discovers bugs or other issues, they will create tasks for the developers or programmers to fix.
User Acceptance Testing (UAT)
The team deploys it to a UAT server when work passes the internal testing phase and is ready for approval. Once in the server, the work will get final client approvals before flipping the switch. The fundamental difference between a UAT and Test server is that 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 the client will use. By doing this, a client can access the product on this server, along with being able to use it and see a real-time view of the outcome. It will function similar to how it would if it were in production. The client can check that the requested features work according to their original thoughts. If the client does not like their initial idea on a feature in UAT, they determine whether they want to launch as-is or change how something works. This can speed up approvals and limit problems after going live.
Staging
Staging is for pre-deployment. It’s like a dress rehearsal. A staging server’s setup is like production with all production configurations, and the team uses it to perform smoke testing. This ensures the code and everything works in a production configuration and architecture. It’s the last step before production. Once the UI developer, backend developer, DevOps, and database administration check everything and it’s an all-go from each, they push the code to production.
Demo
Demo servers are not as common as the other servers, but in certain situations, a client may request to set up a demo server. A demo server is a frozen version of a production server that is usually a few deployments behind the production. When you complete the final work, and the client approves it, 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. A sales and marketing team will usually use this server to promote the development and allow prospects and leads to interact with the product.
Production
Production servers are the final location for all finished and approved work. When you deploy code to a production server, this means everyone has authorized it to go live. The result is considered complete and approved for widespread use at this stage. 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 some 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, which people want to avoid.
As you can see, the servers used in deploying and testing code as part of the SDLC all have different purposes and pass through specific steps. However, the result is always to get a product live in production with as few defects as possible to ensure a fully functioning user interface and positive user experience.
When it comes to Agile, this approach tends to be contradictory to the flexibility Agile offers since switching from server to server is more like the waterfall method and can have long wait times. To do this work and still be Agile, you can modify the approach based on needs and use version control via tools like GitHub and server deployment tools like Jenkins.