Symfony is on version 5 as of writing.

If you are a starting Symfony developer or you have experience in development in Symfony but haven’t worked with your CI / CD or deployment, then this article is for you. Beginners often neglect to understand the importance of environment variables in their applications.

What are environment variables?

In simple terms, environment variables are key / value pairs that are accessible throughout your system’s shell. E.g Web Servers’ Shell. These variables affect the behavior of certain processes running inside the system.

</p>
<pre>echo ${HOME} // HOME is a well known environment variable in most systems.</pre>
<p>

In web development, it is standard practice that the code you write from your development will be shipped in different stages/environments. E.g test, production.

This is where environment variables are typically used. To make my point clearer, supposed you installed doctrine in your Symfony 5 project. In Symfony, environment variables are stored in a file called .env file which saves you from the hassle of setting it in your system (during production, you may want to set in your System’s Variable instead. I’ll explain it later). When using doctrine, you will need to set the value of DATABASE_URL variable with the database connection string like so:

</p>
<pre>DATABASE_URL="mysql://db_user:[email protected]:3306/db_name"</pre>
<p>

Imagine you need to deploy your application into your test server. Normally, the environment variables you used in your development environment is different from environment variables in your test servers. In this case, you need to have different .env file.

The DotEnv Component

The DotEnv Component parses environment files you’ve added in your code. Typically, in development you would want to use values inside your .env file. However, in test environments, you can use .env.test. The production environment is different case. Since these .env files should be committed in your repositories you would not want to expose confidential credentials. As such, production environment variables should be configured on your system’s environment variables.

The DotEnv Component is smart enough to know what to use in each environment. Symfony out of the box supported three default environments – dev, test, and prod. But there is no one stopping you from creating your custom environment as described here. If a particular environment variable is present in your shell or server, the value from .env gets overwritten.

How do DotEnv Component chooses an .env file to use?

By default, in each requests, Symfony will parse .env file. While this is the behavior you may want when developing you may not want it when you are on other environments. When testing the application you may want to use the .env.test file then run a test command specifying the environment like so:

</p>
<pre> php bin/console command_name --env=test</pre>
<p>

Do not be confused with manual testing and automated testing. Our .env.test file here will be used by our automated tests so we have the ability to specifiy environment files to use. 

If you think of manual testing in your test servers, then do a production build instead.

Deployment In Production

As I said earlier, in production, you would always want to use the actual system’s environment variables. Again, you don’t want to worry about the presence of .env in your code since it will get overwritten by the actual system’s environment variable. The DotEnv will get values in your $_SERVER and $_ENV PHP variables and compare it against the .env file in your code. If a particular variable is present on $_SERVER_ and $_ENV it will always take the precedence.

If somehow you may opt not to configure the system’s environment variables, then you may use the Symfony Docs guide explained in here.

I hope somehow you learned something new from this article. Thanks for reading and happy coding 😀