To learn more about the concepts covered in this lesson, you can check out Heroku’s pipelines documentation.
Using Heroku Pipelines to Implement a Deployment Workflow
00:13 This particular workflow uses three separate environments called local, staging, and production. This kind of setup is widely used in professional projects since it allows testing and reviewing new versions before deploying them to production and putting them in front of real users.
00:31 When you use this workflow, you’ll run the application in three separate environments. Development is the local environment. Staging is the preproduction environment used for previews and testing. Production is the live site accessed by final users.
00:48 Previously in this course, you saw how to run the application on your local environment and the production environment on Heroku. Adding a staging environment can greatly benefit the deployment process.
01:00 The main purpose of this environment is to integrate changes from all new branches and to run the integration tests against the build, which will become the next release. Next, you’ll see how to create the staging environment in Heroku and how to create a pipeline to promote versions from staging to production.
01:45 A Heroku pipeline is a group of applications tied together by a workflow. Each one of these applications is an environment in the development workflow, such as staging or production. Using pipelines guarantees that after promotion, production will run the exact same code that you reviewed in staging.
You can then access the app in the same way you accessed the previous app: with your app name, followed by
.herokuapp.com. Now that you have Heroku applications for production and staging, you’re ready to create a Heroku pipeline that links them together.
From now on, you can refer to the production deployment as
prod. Next you’ll see the staging application being added to the same pipeline by the command seen on-screen. This command adds the app
realpython-flask-app-staging to the same pipeline and specifies that the app must be used for the staging stage.
Note that when you run this command, you’ll need to substitute your staging app name in place of the one seen on-screen. This means that the pipeline now consists of two apps,
realpython-flask-app-staging. The first is used as a production environment, and the second one is used as the staging environment. Note that when you try this, you’ll need to substitute your own unique production and staging apps into the lines seen on-screen.
Suppose, for example, that you want to change the message returned by the
index() view again. In that case, you’ll have to edit
app.py and change the string returned by
index(). On-screen, you’ll see the changes being made.
05:54 This command deploys to production the exact same version currently running in staging. As you’ll notice, in this case, there’s no build step since the same build from staging is used and deployed to production.
06:08 You can verify this by going to the production URL and see that the application was promoted and it’s running the latest version. To learn more about working with pipelines and more advanced workflow, check out the Heroku pipelines documentation at the address seen on-screen.
Become a Member to join the conversation.