BEGINNER’S GUIDE

A Guide To Multi-environment Application

If you are new to software development or did not have chance working with multi-versioned applications.

Overview

Multi-environment application is a popular technique used by major organizations. This technique is widely used when we want to add new features, test, debug without worrying about affecting current live product.

The definition of environment

In short, environment is a set of hardware + software + data + system configurations that let a program operates properly.

For example, I want to make an e-commerce website using PHP, and run on LAMP stack. In that case, the environment look like following:

• Hardware: A web server containing application source code. A database server for storing persistent data.
• Software: Linux OS, Apache, PHP installed on web server. MySQL installed on database server. Software may also include PHP extensions and MySQL extensions.
• Application source code
• Configuration: IP filter, Basic authentication credentials, Cookie expiration time, …

Most of developers when doing school assignments or in early days working, we often stored configuration into source code, including sensitive information like encryption key, DB credentials, … It may be fine if you don’t share your source code with others but in collaborative team, it will take more time to set up and let everyone work with same source code in the right way.

I would also stress that, even you are using private repository, there is still a small chance of leaking sensitive information. So, never store credentials or secure keys into source code.

How environments are set up?

Most technical teams use 3–4 environments:

Local environment

This environment is specific for every single developer. Entire database and source code stay in your own machine and you can get your hand dirty as much as you want. It usually takes a day to set up project when you start working at new company.

Staging/Testing/QA environment

This is collaborative environment that all team members have access at a certain level of permission. When your commit are merged to main branch, often master branch, it will be deployed to this environment.

• Staging environment is usually used for integration testing.
• Developers, PMs and Tester should have access to test and confirm whether it works as expected.
• If the feature/fix works on Staging, we will deploy to Production.

Production environment

This is the scariest environment, used by real users, containing real data. Therefore, any changes must be examined carefully before deploying to this environment.

The access control level is also highly restricted. In practice, only Database Analyst (DBA), SysAdmin, CTO and some experienced developers are granted the access.

Most of the time, we only work on Local and Staging:

• We change and test on Local, make sure there is no bugs.
• We merge changes and deploy to Staging, keep testing, hand over task to tester and wait for their confirmation.

In some cases, there are a few differences between Production vs Local/Staging in terms of configuration or data. Therefore when a bug is reported on Production, we cannot reproduce the issue on Local/Staging or vice versa.

Set up environments the right way

CTO/Technical Leader/SysAdmin are often the ones responsible for managing multi-environment infrastructure. Developers only need to follow the instruction to set up and start working.

Actually, the best practice depends on many factors, but in my opinion, there would be some standards:

Quick and easy

The installation should be simple enough, I would prefer running one script or one click. It used to take me whole day at a company to install Gearman, Nginx, MySQL, PHP-FPM, import database, … while in another company, it only took me 1 hour running script.

Synchronization

• Software synchronization: the version of softwares on Staging must be the same as on Production.
• Hardware synchronization: the system resources of Staging and Production must be the same. This is difficult to happen because Production environments have more servers, and the servers are more powerful to deliver the best performance.
• Data synchronization: Data should be entirely or a portion same, however, sensitive information (email, password, phone number, …) must be modified before syncing to Staging/Local.

Same code, different configuration

Configuration such as database credentials, database host, 3rd party API key should be stored in separated files (.env, .json, .config) and such files must be ignored by version control system.

Access Control Level

Access to Production environment must be highly secured. Only authorized members are granted permission at certain level. There are countless stories about junior developers accidentally swipe out production database.

Conclusion

The most important point is, creating multi-environments project must be considered based on technology, level of teams and the nature of project. It is helpful for performing thorough tests before push to live but also a nightmare when come to maintenance if not setting up properly.