The importance of a staging environment (sandbox) in a web project

What are the different types of website environments?

Whatever the web project involved: rebuild, migration, change of theme or simply installation or update of a module, a good management of the different environments is essential. But before getting to the heart of the matter, let’s take stock of what an environment is in terms of a website.

In the context of a web project, we tend to talk about the development environment. It is a set of tools and applications serving the website and allowing to develop, manage source files, or work directly on the source code. The environment is made up of several elements:

• A set of services, which, as part of a web site will correspond to the web server, database, FTP server, cache server…
  
  
• A source code editor which will allow to perform developments and modifications directly into the code of the site
  
  
• A version manager allowing to keep a chronology of all the modifications carried out in the source code

One would think that a simple development environment would be enough to manage a website properly. This is obviously not the case. In many situations, different environments will be necessary, each with its own role:

• The development environment: as its name suggests, this is the developer’s own environment, generally managed directly by the development agency. We have detailed it previously, but it is in this environment that all the modification or creation work will be carried out. These environments can be multiplied, in particular with a local version.
  
  
• The production environment: it corresponds to the environment used by the customer. The front and back office of a website are managed directly on the production environment. It is also this environment that will be visible to search engines and website visitors. It must be fully functional.
  
  
• The pre-production (or staging) environment: this is the intermediate environment. It is the link between the development environment and the production environment. When modifications are made on the development part, they are first sent to staging to be tested and then to the production environment.
  Many merchants do not have the skill or time to use this type of environment. They expose themselves to great risks by skipping this intermediary and working directly on production. We will analyze in detail the importance of this environment as well as the solutions to integrate it efficiently into your web project.

What is a pre-production environment?

The pre-production environment, also known as the staging environment, is the intermediate step, the one that allows to test and validate the modifications made.

This environment is generally not accessible to everyone and is often protected in different ways (password, .htaccess file, IP address restrictions etc.) in order to make it inaccessible to all unwanted users and search engines.

Preproduction is placed on another url than production, often on a sub-domain such as preprod.nameofthesite.com. The environment is identical to that of production so that the tests and verifications carried out are relevant. 

Why working on pre-production?

Working directly on the production environment is extremely risky. Indeed, any modification made in the structure of a website can lead to a breakdown. For a merchant, a breakdown automatically means a loss of turnover. This will then require a quick intervention which will also cost money and the operation will therefore be a real failure.

To avoid this kind of inconvenience, which can be really problematic, it is always advisable to work and validate the modifications on a pre-production environment.

When to use pre-production?

As part of a website, and especially a PrestaShop store, many modifications are likely to create problems during their integration. Here are the most common ones:

• Installation of a new theme: the PrestaShop theme will affect all the template files (.tpl) of the shop. These files contain a large number of rules that define the display of the elements of the site as well as various JavaScript and CSS files. The modification of these elements has directly an impact on the visual and it is very quickly possible to make a type of page (product, category, etc.) inaccessible following a bad manipulation. These visual modifications can also generate ergonomic issues that are truly harmful for a PrestaShop store. The use of a pre-production environment will allow here to perform all the necessary tests before releasing modifications.
  
  
• Installation of a new module: the PrestaShop solution benefits from a very rich catalog of modules with a wide range of practical applications. You can find modules for managing the main menu, filter navigation, tracking, payment or the display of additional blocks. Depending on the field of action, it is obvious that the installation of this type of application can have a considerable impact on the store. A badly configured payment module may prevent Internet users from validating an order, which automatically means a loss of turnover. The Internet user also risks not coming back to order on the shop. A menu module will directly impact the navigation and the risk of making some pages inaccessible is great. The impact on the operation and reputation of the shop is huge and can create irreversible damage. Checking the compatibility of a module with the version of the PrestaShop solution is essential, but does not always prevent you from encountering problems later on, during installation… Once again, the configuration work on a pre-production environment remains the safest solution.
  
  
• Updating a module: in the same way as the installation of a new module, a simple update can quickly break the functioning of the module concerned because of an unanticipated incompatibility. It can indeed happen that the update of a module generates conflicts with the operation of another, or that it causes integration problems with the theme of the site. A bad management of the update can also trigger the deletion of some changes that had been made previously. If backups have not been made beforehand, this can be a real problem. In order to anticipate these kinds of incompatibilities, the staging environment is necessary.
  
  
• Upgrading the solution: when you use a CMS (Content Manager System), you are using a solution that is constantly evolving. Tools such as PrestaShop or WordPress regularly benefit from updates, sometimes minor, sometimes major. In any case, making these updates without worrying about the impact they could have on all the elements of the site is very risky. Analyzing the backlog of changes and impacted elements is very important, and the use of a sandbox to anticipate problems is essential.
  
  
• Other file modifications: Sometimes the installed modules or themes do not allow the display and operation modifications desired. In such situations, it is possible to directly modify the .tpl files or the code of the modules. As with any modification you make, and especially if you are not a developer, you will surely start by groping around. You will try to understand how the code is built, and identify the parameter that will allow you to make the desired modification. It is in this kind of situation that errors are made, errors that can impact and break elements that are essential to the correct functioning of the website. The pre-production environment then allows you to meet this need, by offering the possibility to make the modifications in complete security.

The Parachute solution

If it seems obvious that a pre-production environment is essential to the good health of a website, it is important to understand what pushes e-merchants to often work directly in production. For a pre-production version to be fully functional, a simple copy of the production is not enough. It is necessary to make file configurations and modifications of database elements that require technical skills and that have a certain cost. It is with this in mind that the Parachute solution was developed.

What is the Parachute solution?

Parachute is a solution for cloning a website to a pre-production environment that allows you to perform various developments, tests and other technical operations without the risk of damaging the production version of the shop. Parachute is the ideal solution to work in pre-production.

Indeed, Parachute doesn’t just create a simple copy of the online site files. When you clone your production version through Parachute, it is automatically configured to work as if you were working on the production site. No need for technical skills to make it work, it already does! Moreover, you have at your disposal a real workspace from which you can make backups at different stages of your work, create personalized accesses for your webmaster for example, or go back if a modification does not suit you. All changes made are visible and historicized thanks to a powerful tracking tool and can be cancelled at any time. When you are convinced of the changes, you can retrieve, in one click, only the modified files that differ from the production version for a release with complete peace of mind.

How much is the Parachute solution?

Parachute is available on subscription from 49€ per month. It’s without commitment, it means that you can unsubscribe at any time, when you don’t need to work on your site for example, and then re-subscribe when you need your Parachute again.

The solution can be tested free of charge and without obligation for 3 days. During this period, no banking information is requested and all the functionalities of the solution are available.