You don't normally commit the environment variables into your code base as that would be effectively the same as directly using the values in your source code. As an example, we plan to use an environment variable called stage to change the behavior of our application. For example, if the stage is production, we show a message, we are in production. For preview, we say you are looking at a preview of the website. And for development, we might want to enable some development only features. However, if stage is not one of these values, then we have probably done something wrong and we show an error message as we know we can provide this environment variable using an end file, for example, set the stage to development.

However, if you were to commit this file, then all of our deployments would behave as if they were in development mode. And since that is not something that we want, we are not going to commit this file because the environment variables are not stored in our code. We need a workflow to supply them to our application during deployment, since we haven't provided the stage environment variable, our production application is not looking very happy. Exact steps for supplying the environment variables will depend upon your CICD platform. For this demo, we will be using versal, but similar steps exist for any modern system with Vercel. Under our project settings, we can find a section dedicated

to environment variables from the environment dropdown. First we select only the production environment, then we provide stage as the key. And for the value we will use production and we save this particular environment variable. With the production environment variable created, we will repeat the same process for the other environments. We will select preview next and once more we will use stage as the key. And for the value, this time we will provide preview, click save. And finally we will select the development environment. From the dropdown use stage is the key and for the value. This time we will provide development with the values

provided for the different environments. Let's go ahead and create a new deployment for our production instance. From our deployments page, we can create a new deployment. We select our main branch and click create deployment. This will trigger a new deployment for our production application. And once that deployment is complete, when we visit our production website, again, we now see a healthy message. Remember that we created the stage environment variable for production as well as for preview. So let's kick off a new pull request to get a new preview environment. Once the pull request is created, will automatically spin up a new preview environment.

And if you visit this preview version of our application, we see a nice message informing us that we are currently in preview mode. So we have the environment variables automatically being provided by our CD pipeline as a part of the deployment. The question you should now have is how do we provide the values during development? Once more, your workflow will depend upon how your deployment platform allows you to access the environment variables locally. But with Versa cell, you can use the Versa cell CLI, which you can install from NPM using NPMI, versa minus G. Once the CLI is installed, we run Versal link

to link our local repo to the Versal project. In the cloud, we select the project folder along with the team name and the project name in the cloud. This will create a new folder Called Versal, which will contain the configuration that the CLI will use in order to carry out additional commands. Now that we have the Versal CLI configured for our project, all that we need to do in order to pull down environment variables is to run Versal en pull. This will create a new N file called N Local. Additionally, the CLI automatically adds it to GI Ignore, so we don't end up committing it by mistake.

Next year supports loading environment variables automatically from a file with such a name. Note that while our environment only contains one variable right now, as your projects get more complex, the task of running versa and pull will feel much simpler than having to pass a bunch of variables around in your team. Now that we have this local and file created, if you run our project again, you can see that it was automatically picked up by next yes, which provided the value to our application. And we see our custom message development mode enabled. Note that using environment variables to determine the behavior

of our application has another advantage that if we ever want to run a production version of our application locally for testing and debugging, all we need to do is to pull the production environment variables to our local machine cel and Full takes an optional argument called Environment. And for the value we provide production, this will pull down the environment variables for our production environment and place them into our end local file. Note that Versal automatically provides a bunch of additional environment variables for the production environment, which is why this file is getting quite big. But within all these environment variables,

we can still see our custom environment variable called stage with the value production. So now if we locally run our application, again, it'll behave as if it was running in production. And we see the message that we wrote specific to this stage.