Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Run Consistent Dev, Stage & Prod Docker Environments

    Mark ShustMark Shust

    Docker makes it easy to have near-full environment parity between dev, stage and prod. In this lesson we’ll go over a typical setup within Docker Compose, and how to manage backing services between dev, stage and prod.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson




    Instructor: We define the app surfaces we want to use within our Docker Compose YAML file. Docker makes it easy to run consistent environments between dev, stage, and prod.

    Because the images and versions we define in this YAML file are the exact images and versions we use on staging and production, we can ensure we have 100 percent parity between environments, and that differences between environments will never exist.

    Third-party backing services are typically configured with environment variables. This allows the use of the exact same code base between environments, and requests are directed to that appropriate backing service depending on the value of the environment variables.

    Let's take an example of Google Analytics. Say you want to test the functionality of your analytics code in a local environment, but don't want it to affect prod. You would simply create a new Google Analytics account, and use the ID of that test account within an environment variable.

    Then you define the environment variable within your .env file. Take the code snippet supplied from your Google Analytics account, then substitute where it calls a reference to your Analytics account number with a reference to your environment variable.

    When you start your Docker container, your environment variables will be set from your .env file, meaning that the test Analytics ID will be applied. When you deploy code through staging and production, you can use your different related Analytics IDs that are defined within each specific environment's .env file.

    Since .env files should not be committed to version control systems, you should most likely create the process of adding and changing environment variables to your deployment process. This way, you could be assured that the correct environment variables are set upon deployments to the related environment.