A couple of weeks ago, we deployed an often requested feature to the Hyperlane platform: the option to manage environment variables from the interface.
Environment variables are defined on a system-wide level. The variables can be utilized in the code of your website, for example, but also in a shell script that you create to import some data to your database. By managing these variables in one place, on the system, you don't have to worry about where to put them in your code. This way, you can keep your code and (possibly sensitive) data separated.
In the Hyperlane platform, we made it as easy as possible to configure environment variables and make them available in your project settings.
The major benefits of using environment variables are:
- Easy configuration
- Better security
- Fewer production mistakes
In this blog article, we will dig into each of them and explain how to implement environment variables in your development workflow.
Why Environment Variables can make your development process better
Configuration
Working with environment variables on your website can have a lot of positive effects on your development workflows. When using them, you should only have to worry once about the setup and configuration of your application.
For example, on the development environment, you might want to disable caching and show more debug logging. On the production environment, you definitely do not want to enable debug logging as it will lead to a performance decrease.
Having to create separate configuration files for each situation leads to a lot of overhead and is not really scalable. With environment variables, you can just create a single config and tweak it based on the values you define.
Security
Storing passwords or other sensitive information in your version control system, like Git, is never a good idea. So instead of setting the password directly in the configuration files in your codebase, you can use a reference to an environment variable.
Another advantage of separating code and configuration is that when a password or a third party key has been changed, you will only have to update the environment variable. No code changes or deployments need to occur to take effect.
No more production mistakes
A mistake that all of us have probably made in our development careers, is working on a testing environment with configuration of the production environment. For example, the outgoing mail server that was configured on production sneaks in after a restore or backup to a local environment. Sending out test mails to your customers is, well, something that is better avoided right?
If your mail plugin supports the use of environment variables to configure it, you should do this. You will not have to worry about that scheduled task which is sending out mails of some test orders you created on your testing environment. When you have configured your non-production environments to make use of a mail catcher for example, they will never arrive in the mailbox of your valued customers.
How to implement Environment Variables in the Hyperlane development workflow
Hyperlane makes it super easy to configure environment variables. To create new variables, go to the details page of your website and add your own key-value pair. You will see that there are already some read-only variables defined. These variables are created by the platform and can not be changed as this might break the functionality of the website.
Of course, you will have to prepare your own code to make use of these variables. For WordPress and Craft projects, you can use the excellent getenv() method in PHP. You can read all about it here: http://php.net/manual/en/function.getenv.php
A more practical example can be found when you create a new Craft 3 project on Hyperlane. When you check out the Git repository that gets created for you, you can see that the database configuration file makes use of environment variables. The file config/db.php looks like this:
<?php
/**
* Database Configuration
*
* All of your system's database connection settings go in here. You can see a
* list of the available settings in vendor/craftcms/cms/src/config/DbConfig.php.
*
* @see craft\config\DbConfig
*/
return [
'driver' => getenv('DB_DRIVER'),
'server' => getenv('DB_HOST'),
'user' => getenv('DB_USER'),
'password' => getenv('DB_PASSWORD'),
'database' => getenv('DB_NAME'),
'schema' => getenv('DB_SCHEMA'),
'tablePrefix' => getenv('DB_TABLE_PREFIX'),
'port' => getenv('DB_PORT')
];
No more .env files
Last but not least, we have stepped away from the .env files, and are now injecting the variables directly into the webserver. This way, performance has been boosted as there are no more read operations on the .env file on every single request.
Putting it into practice
Want to give it a try? Start your free trial now and check out our documentation for additional information.
If you need any assistance in making your code environment-variable-ready, do not hesitate to contact us at [email protected]
