The development team has gathered the requirements. For weeks, they have been working non-stop, tweaking the code, unit testing, doing QA, and preparing for the moment the project goes live. They have taken into account every eventuality, so, what could go wrong?
Every software developer who has ever gone live knows the anxiety that comes with going into production. It doesn’t matter how much preparation and testing you’ve done beforehand, there is that dreadful feeling that you missed something, or that something will go wrong.
It can be something as silly as forgetting to update the static file path or it might be something as arcane 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, the developers are constrained, some bugs can be hot fixed, while others will require taking the project down for maintenance.
The question is, what does this all mean for the client? How is your relationship with the project going to change once you get into production? What should you be on the lookout for? What can you do on your end to make sure that the process goes smoothly?.
How is software made?
The software development life cycle (SDLC for short) is the name of a set of standard practices aimed at facilitating the creation of software. Depending on who you ask, this process is divided into 6 to 8 steps: Planning, Requirements, Design, Build, Document, Test, Deploy, Maintain.
In the first couple of stages, the development team gathers information about the product. Engineers try to solve the following questions: What is it trying to solve? What kind of data is it going to be working with? Does it need to interact with other systems or is it going to be standalone? Is it going to be hosted on the cloud or is the client using personal servers?
This process lays down the foundations for what’s going to come after. Understanding the nature of the project and the need of the client from the very beginning means that the team has a better idea of how to approach the design process.
From the design/prototype stage forward, the developers have 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, this is often called the software development environment (SDE).
Traditionally, you have 3 different environments in the SDE itself: the development environment, the stage 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 it when the restaurant is full and they have to cook for the customers? Or would it make more sense to get creative when the restaurant is closed and they have ample time to think and try out new combinations?
The development environment is just that – a controlled space where the developers can start designing, prototyping, and shaping the project. In most cases, the development environment is set up in local hardware and facilitated via a Git repository. At this stage, the project is in its infancy, it’s buggy, lacking critical features, and barely working – if at all.
There are different paradigms on how to set up a development environment, but most developers like this environment to be as isolated as possible. That 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. That way they can keep tight control on what libraries are being used.
From design to documenting, the client gets to see snippets of the project: screenshots, guided presentations, or even a functioning prototype of some of the modules. At this point, the developers are looking for feedback on how the project is aligning with the client’s goals, testing will come later.
Production environment
Putting the project in the production environment is what people typically call “going live.” The project is ready to be used, but the process is still far from over. In SDLC terms, the project is moved over to the production environment at the end of the testing stage and it goes live when you reach deployment.
There is an in-between environment called a staging environment that acts as a bridge between development and production. The staging environment is as close as anyone can get to production without actually going live.
In other words, the project is moved over to the servers, and it’s set up as if it was going to be deployed. At this step, final preparations are done, required databases are migrated, and one final but very important series of tests is done.
Think about it this way: so far the project has existed in a laboratory specially designed to preserve its integrity, but once it’s moved over to another place things can go wrong. There are tools like Docker that help with the migration process by creating a production environment that is as close as possible to the development environment.
But even then, a full set of tests is run to make sure that the project works as expected and that there aren’t any conflicts.
At this stage, the developers can share access with the client. Thus, you can see this as a “demo” where the client tries the project in its entirety. The idea here is to get a final round of feedback and, if everything is working according to their expectations, the Ok is given to go live.
Production is the environment where minor things can and will go wrong, but it’s also the stage where the project must deliver on its goals. This is the point where any critical error will cost the client time and money. As such, it’s imperative that even if bugs are found the project can keep going while fixes are rolled out.
How updates are handled depends on the nature of the project and the methodology of the team. For example, agile teams strive to make changes as fast as possible, but critical fixes may require downtime that has to be scheduled during low workload periods.
At this point, the client is both a user and a beta tester. As bugs are found IT keeps track of tickets, and solutions are implemented as fast as possible. Once the kinks are ironed out, the project moves to the maintenance phase, and everyone can let out a sigh of relief as the most critical part of the project has passed.
Going from development to production is a very delicate process that requires dedication and using tools like the aforementioned Docker to ease the process. It’s one of those areas where a DevOps expert can shine and help push the project forward.
The move from development to production can be tense, but a strong communication between client and developers as well as a good planning/testing strategy can help the process and push it to its conclusion.
