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.
Thanks. Very clear article
Superb article, very simple, very clear & well described tutorial.
Thanks
very clear article and precise.
thanks
Thanks, was looking for an exhaustive list of environments; this is exactly what I needed.
No Problem! Glad we could help you out, thank you for letting us know we helped!
I enjoyed reading this article, which is why I feel compelled to point out a couple of parts where you’re wrong in my opinion. This is from my 20 years of experience as a developer, tech lead and now a software engineering manager with a top down view of various operations in the software development pipeline.
1. Under both Development & Test, you’ve missed a critical component here and that is access to a dev database. Unless you’re working in an embedded environment or your component is a standalone piece with no I/O, you’re going to need some kind of ‘dev-level’ database. How else can you test the component actually does what is required with any real confidence? Stubbing ‘fake’ data isn’t enough. Early database considerations (new stored procs etc) can be considered and potentially dev tested at this level.
2. Under Test, you talk about a QA Tester? I think this is slightly confusing. At this stage, an efficient process will have a developer (usually from the same team) Code QA the work and simply validate it. If it’s a bug fix, they’ll validate the problem is fixed. If it’s a whole new service, they’ll validate that it operates as expected. This isn’t really testing at all. This is just making sure from a cursory glance that it doesn’t explode which is superficial. The commitment here is a Code QA to ensure that it is safe, maintainable and high quality. Most QA’ers need to run the software to understand the code paths but for some changes, they might not even run it at all. Do not confuse this stage with testing.
3. Under UAT you’ve got: “Once in the server the work will get final client approvals before flipping the switch”? Wooooah, slow down there, you’re nowhere near flipping the switch. What about Dev Integration? What about if there are dependencies on other services, that are being changed by a different team? Are they backwards compatible? These are questions that you answer now (or preferably on Dev). What about those stored procedures that I mentioned before? You can’t just start throwing new procs on production or even worse change existing ones and hope it just works. You’re going to throw a grenade into your multi-million pound product here.. All that stuff requires that developers, tech leads etc, understand the impact on other services and this requires validation. THIS is where your real testing begins with the aid of actual testers AND YES, if there are issues and defects and holes in your solution become apparent, you should actually go back to a Dev environment. After all, most businesses have a single UAT database that is shared across various products (remember that I/O I talked about). Do you really want someone’s badly developed service that shouldn’t have been QA passed boffing up and slowing down your UAT database? Hopefully your database team (and yes, all good software houses should have one) has proven off their changes on that dev database I mentioned and are now ready to promote their QA’d DB changes to UAT. Now you’ve got to put your service, bug fix, UI etc on there and a tester(s) should run a comprehensive set of cases based off a script to ensure that this isn’t going to wipe out your premium product. Finally, there’s no mention that now is probably the time you would look to run some kind of regression tests as well. Just because your new service is doing what you expected, doesn’t mean it’s not smashed up something else that you haven’t thought about. Most well run operations have a standard set of regressions that are run on every project piece to validate other parts of the system are still running as expected.
4. Under Staging, which I’m choosing to interpret as basically a glorified term for Pre-Production, you’ve got “…… production with all production configurations….” followed by ” …. UI developer, backend developer, DevOps, and database administration check everything and it’s an all-go from each, they push the code to production….”? Stop. Read that back. Read it again. There’s one thing very wrong with this statement… actually, there’s two but let’s go with the first… have you worked it out yet? This is a Pre-Production environment, which is hitting your production database yet you’ve not pushed your database changes yet? Where’s your new service pulling it’s data from exactly? The existing procs? But they’ve not been updated? The new procs? But they aren’t there, you’ve just said the DBA is checking everything is good to go? Database changes HAVE to go first as a totally independent and decoupled exercise. It is one of the trickiest parts of maintaining a software system that cannot go ‘down’ (i.e. have downtime for updates). Really, your database changes should be pushed live (once tested of course) during or at least no later than the final UAT testing phase, to clear the path for the upcoming changes. Your second issue is you’ve coupled all your releases together which in most production systems is unwise. What happens in the event of a rollback? The last thing you want to do is roll absolutely everything back… the UI, the backend, corresponding services etc. It’s a managers worst nightmare. If you are updating an already existing system, you want your final component to be the switch-on for any new functionality and you should aim to have it be the easiest one to rollback, in case it does explode. As the frontend to your product, the UI is usually the easiest way of switching on/off your underlying new code. This might not apply to completely new services as they usually won’t be consumed until your new parts are all there. Always important to think about it though.
5. Under Production, you mention version control. I don’t think this really has any relevance here unless you are confusing it with some kind of version management/activation system? This isn’t the same thing. As for dev’ing, you shouldn’t mess around on production boxes regardless of if you use Git. Simple.
Cheers.
J
Joe,
Your comment on the post is very detailed from an engineering perspective, and I can tell it’s specific to your experience. I suggest you put together your own blog where you can teach others your vast knowledge of how your development and delivery process works. Most of our readers are small business owners and are not highly technical. At least, that is the target market for our blog posts. It’s really an overview for them to understand the different environments, phases of development, etc. It’s our consultants that have the knowledge and experience on such details you mentioned in your comment. If you can create a more technically driven blog, I’d be glad to post the link to those that want a deeper technical understanding. Thanks for your participation.
Rey Ortega
Great response Rey. The original article was clearly written as a simple to understand piece providing a higher level overview to individuals who are within touching distance of the DEV to Production cycles. (I sent the link to my product analyst interns who all understood immediately :-).
Joe’s article went deeper and was interesting too but definitely overkill and too specific for the intended audience. To be honest I’m also surprised that some other denizen of the web hasn’t told Joe that his response was NOT comprehensive enough or detailed enough 😐
When it comes to clear communication, sometimes we should remember that less is more.
Good points
This was a great read for someone just getting going in project management within a software company it helped me get a good understanding. Keep up the great work!
Good article for starters in software company.. It cleared my doubts on server environments
Very good information.
Thank you for sharing these type of article, Please Keep Update