Going live is a critical step in any process. A good understanding of the difference between development and production environments is critical to helping everyone assess risks and how to address them.
The development team gathered the requirements. For weeks, they worked nonstop, tweaking the code, unit testing, doing quality control, and preparing for the moment the project launched. They took every eventuality into account, so what could go wrong?
Every software developer who has ever gone live knows the anxiety that comes with going into production. No matter how much preparation and testing you've done beforehand, there's that awful feeling that you've missed something or that something is going to go wrong.
It could be something as silly as forgetting to update the static file path or it could be something as mysterious as not having the same version of a library on the live server (yes, people still deploy their projects without using containers).
When a project is still in development, software engineers have the flexibility to change the code or refactor it as needed. When the project is live, developers are restricted, some bugs can be hot-fixed, while others will require the project to be taken down for maintenance.
The question is: what does all this mean for the customer? How will your relationship with the project change once you go into production? What should you watch out for? What can you do to ensure the process goes smoothly?
How is the software made?
The software development life cycle (SDLC for short) is the name for a set of standard practices that aim to make software creation easier. Depending on who you ask, this process is divided into 6 to 8 steps: Planning, Requirements, Design, Construction, Documentation, Testing, Deployment, Maintenance.
In the first steps, the development team gathers information about the product. Engineers try to solve the following questions: What is this trying to solve? What type of data will it work with? Does it need to interact with other systems or will it be independent? Will it be hosted in the cloud or will the client use personal servers?
This process lays the foundation for what comes next. Understanding the nature of the project and the client's need from the beginning means the team will have a better idea of how to approach the design process.
From the design/prototype stage onwards, developers need to set up an environment. An environment is, for lack of a better term, a virtual space where the application is being developed.
For example, if I build a sofa in my living room, the physical space I'm using, the tools I'm working with, and the materials are the environment . In the case of software development, the environment is the hardware and software tools that are being used in the development process, often called the software development environment (SDE).
Traditionally, you have three different environments within the SDE itself: the development environment, the staging environment, and the production environment.
The development environment
Imagine for a second that a chef is trying to create a new dish. Would they do this when the restaurant is busy and they have to cook for customers? Or would it make more sense to be creative when the restaurant is closed and they have enough time to think and try new combinations?
The development environment is just that – a controlled space where developers can begin designing, prototyping, and shaping the project. In most cases, the development environment is set up on local hardware and facilitated through a Git repository. At this stage, the project is in its infancy, has bugs, lacks critical features, and barely works – if at all.
There are different paradigms for how to set up a development environment, but most developers like this environment to be as isolated as possible. This way, bugs due to unknown software and hardware are avoided.
As a quick example, most Python developers set up a virtual environment with a fresh copy of Python when starting a new project. This way they can keep tight control over which libraries are being used.
From design to documentation, the customer can see excerpts of the project: screenshots, guided presentations or even a working prototype of some of the modules. At this point, developers are seeking feedback on how the project is aligning with the customer's goals, testing will come later.
Production environment
Getting the project into the production environment is what people typically call “going live.” The project is ready to be used, but the process is still far from finished. In terms of SDLC, the project is moved to the production environment at the end of the testing stage and goes live when deployment is achieved.
There is an intermediate environment called the test environment that acts as a bridge between development and production. The test environment is the closest one can get to production without actually going live.
In other words, the project is transferred to the servers and configured as if it were to be deployed. In this step, final preparations are made, the necessary databases are migrated, and a final but very important series of tests are performed.
Think of it this way: until now the project has existed in a laboratory specially designed to preserve its integrity, but once it is transferred to another location things can go wrong. There are tools like Docker that help with the migration process, creating a production environment as close as possible to the development environment.
But even then, a full suite of tests are run to ensure that the project works as expected and that there are no conflicts.
At this stage, developers can share access with the customer. So, you can see this as a “demo” where the client experiences the project in full. The idea here is to get a final round of feedback, and if everything is working according to your expectations, you're given the OK to go live.
Production is the environment where little things can and will go wrong, but it is also the stage where the project must meet its objectives. This is the point where any critical error will cost the customer time and money. As such, it is imperative that even if bugs are found, the project can continue while fixes are implemented.
How updates are handled depends on the nature of the project and the team's methodology. For example, agile teams strive to make changes as quickly as possible, but critical fixes may require downtime that must be scheduled during periods of low workload.
At this point, the customer is a user and a beta tester. As bugs are found, IT monitors tickets and solutions are implemented as quickly as possible. Once the problems are resolved, the project moves into the maintenance phase and everyone can breathe a sigh of relief when the most critical part of the project is over.
Going from development to production is a very delicate process that requires dedication and the use of tools such as the aforementioned Docker to facilitate the process. It's one of those areas where a DevOps expert can shine and help drive the project forward.
The transition from development to production can be tense, but strong communication between client and developers as well as a good planning/testing strategy can help the process and bring it to completion.
