In our blog about software environments we took you behind the scenes in the world of web and app development. We discussed the different types of environments developers work with, and their unique qualities and functions. Need to catch up? You can find our blog about the basics of software environments here. Now that we’re familiar with the basics, we’re going to dive deeper into the topic of software environments. This blog is the first of a series with the hopes of highlighting the values of maintaining multiple environments for your projects, and how using environment variables can simplify this maintenance process.

Environments in Software Development

As explained in our last blog about software environments: A software environment is where the technical development and testing of an application or website takes place. An environment in software development consists of the infrastructure into which your application is deployed or published. This infrastructure may consist of one or more databases, services and/or third party APIs.

Why do we need multiple environments?

When developing software applications, most developers will have to maintain multiple environments for their projects. We have taken three scenarios that explain why separating your infrastructure into multiple environments is something to consider when developing an application or website.

Scenario 1

If you have already rolled out version 1 of your application to the market, and the development team is working on a version 2, these new changes should be tested before it becomes accessible to end-users. While developers develop version 2, the end-users should still be able to use version 1 without issue. Having multiple environments lets you continuously develop, test and deploy, which can greatly optimize your agile ways of working.

Scenario 2

If the developers are working in the same environment available as the end-users, it can become an issue when they have to add mock data to test certain features. It may also mean that while testing, some parts of your application are temporarily not accessible for your end-users. Having separate environments bypasses this by allowing you continuously write, deploy, and adapt code without having to worry about breaking functionalities for the end-users.

Scenario 3

The protection of user data is key. At Lizard Global, we make sure that only a few people within our team have access to the production environment. All other members working on the project never get to see live user data. This reduces the chances of accidental sensitive data leaks and other data-related mistakes. Additionally, in the unlikely scenario that something does go wrong, we can rule out the team members that don’t have access to the production environment and data. Strictly speaking, only the lead developer should have access to perform deployments, along with the assigned Data Protection Officer.

Recommended environments for your development process

At Lizard Global, we work agile, which requires our team to continuously make changes to a product so that it can evolve with the market’s needs. In order to do this, we maintain three separate environments: development, staging, and production. This way, we make sure that the processes of development, testing, and deployment can be as seamless as possible with minimal production error.

Development

This is the environment setup for developer testing. Most often the development environment will be set up in the developer’s local machine. Any new development changes, such as new features or hotfixes, should be first tested by the developer(s) in a development environment before being deployed for UAT (User Acceptance Testing) or to the end-users.

It is also important to note that a bigger project likely involves multiple developers. This would mean that it is also good to consider incorporating a Version Control System (VCS) with CI and Gitflow to manage and maintain your codebase for the separate environments.

Staging

The developed code will then have to be rigorously tested. It will be an advantage to have this environment separate from the development environment so that developers can continue developing new features, while another set of features are being tested. Therefore, the Staging environment can be solely for the purpose of testing based on a set of test cases until approved as ready for production.

Production

Once the approved set of changes have been approved on the staging environment, the new set of features can be deployed to the production environment and made available to the end-users.

What are environment variables and why should we use them?

While having multiple environments for your project has its advantages, it is important that developers can switch between these environments to do hotfixes in production, develop new features in development, deploy a new version to staging for testing without too much effort or error. When working with different environments, developers should be mindful to deploy the correct code base and configurations to the correct environment.

It’s a bad idea to hard code these configurations and change it manually, based on the environment you deploy to. Imagine doing a hotfix to the production which is deployed to the production environment, but you forgot to change the configurations from development database to production database. If you are lucky it may cause chaos only for a few minutes until you deploy it again with the correct configurations. However, this is not a chance worth taking, especially when there is a way to prevent this from happening. This is where the environment variables come into play.
An environment variable can be defined as a dynamic object on a computer. It contains a value that is not bound to a specific software program. Environment variables help software programs identify what directory to install certain files, where to store temporary files, and where to find user profile settings. Environment variables are key-value pairs defined based on the system environment that your application is running on. With environment variables, we can set our service endpoints, database configurations, API Keys for third party services, for each of our environments, so that when your application is running on multiple environments, it will automatically lookup the corresponding variables. This will be a one-time setup and you are good to go ahead with your development and deployments without having to deal with deployment nightmares.

Need a hand?

At Lizard Global, one of our core values is transparency to our clients and end-users, which is why we write blogs that shine a light on our technical processes. We understand that topics like software environments and technical app/web development can be a tough cookie to get familiar with. That’s why we gladly lend you a hand! If you want to know more about software environments or other technical topics, feel free to get in touch with us via our website or on Instagram, Facebook, and LinkedIn. We’d love to tell you all about our passion for web/app development and its technical specifications.

Stay tuned for more blogs about Lizard Global’s technical processes and follow us on our social media channels