.png)
Establishing different project environments for your live project, your development server, and your staging server will give you the ability to test your software in increasingly complex environments. It is crucial for your ability to deploy to your live server with peace of mind. A typical development cycle consists of development, integration, testing and QA, staging, and finally production.
This is where your projects are actively being worked on and new features are in progress. The development environment is usually a combination of the computers used by the developers and maybe a cloud-hosted server for testing.
This is where you'll test various integrations with external services and sources, i.e. Facebook, Stripe, or your favorite CRM or BI tool. It's important not to skip this step in order to make sure your users will have the necessary integrations. Most integrations will have a "development mode," where you can test with sample data rather than real data, which will ensure you don't modify live data or input real credit card information while testing.
This is where you'll test the functionality of the project and run user stories. Testing and QA is usually performed first in the development environment or in a special testing environment. In general, if developer A worked on a feature, you should have developer B test the feature, and vice versa.
Better yet, having a dedicated QA engineer will help ensure your QA is complete and thorough. By having a dedicated QA resource perform testing, you can ensure that someone without intimate knowledge of the system can perform the necessary tasks and run through the desired user flows.
Sometimes when a developer performs testing, they may miss bugs because they know how it should work, but not all end users will know exactly how your system will work. More importantly, end users don't know what doesn't work; whereas one of your developers might deliberately avoid clicking the "Login with Facebook" button when they're already logged in with Google because they know you can't use both at the same time, the end users (or your dedicated QA resource) might try to login with both simultaneously and encounter an error.
Think of this as a dress rehearsal for deploying to production. The staging environment should be as close as possible to the production environment, with a database copy and a few testing users. Setting up a robust staging environment may take some time and effort, but it's worth it in the end. All the other environments up to this point have not utilized real data, but this changes with staging.
Here are just a few reasons why using real data to test is important.
Usually, in order to test quickly, your testers will only create just enough data to test each scenario once. However, the quantity of real-world data for your product might be orders of magnitude greater than the testing data, which can greatly affect system performance. If you're using an inefficient database, have inefficient code, or a slow server, you'll discover these issues in the staging environment.
We've all been guilty of using unrealistic test data before. For example, maybe an input field asks you to type in your first, middle, and last name, and you type in "testing" for all three. However, after you roll out to live users, you discover some users are having trouble signing up because they don't have middle names and you accidentally made all three fields required.
When choosing someone to put together test data for a feature, it's useful to have someone who didn't work on the implementation for the feature in question.
If your test server is locally hosted, i.e. it exists on your (or your developer's) personal machine, it likely is different from your production server. Different servers have different technologies, especially when it comes to web hosting, and you might find that parts of your backend don't work when deployed to AWS, for example.
Or maybe you use a managed hosting solution that doesn't allow you to configure your TCP ports, and you find that you can't open ports 443 and 2197 to send iOS notifications.
Your staging server would ideally be hosted on the same provider as your production server, so you can discover any server issues early and fix them before deploying to production.
This is the live project that end users use. If you followed the previous steps, you should have a smooth production deployment with no major bugs. Using the lessons learned from deploying to staging, you can have a detailed production deployment plan and minimize downtime for users.
The detailed production deployment plan also gives you a repeatable process, and repeatable processes are opportunities for automation. We'll discuss automating deployment when we get to deployment pipelines.
Running a business is hard,
Software development shouldn't be ✌️
