Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Using Heroku Pipelines to Implement a Deployment Workflow
To learn more about the concepts covered in this lesson, you can check out Heroku’s pipelines documentation.
00:00 Using Heroku Pipelines to Implement a Deployment Workflow. In this section of the course, you’ll learn how to implement a workflow for your application deployment using Heroku pipelines.
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:20 The diagram you can see on-screen shows this workflow. Here you can see the three environments, the activities that happen in each of them, and the deployment and promotion steps.
01:32 Implementing a workflow in Heroku consists of two steps: creating separate applications for staging and production, making both applications part of the same pipeline.
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.
02:05 In this course, the previously created Heroku application is used as the production environment. You should create a new Heroku app for the staging environment using the command seen on-screen.
02:19
This first command creates a new Heroku app named realpython-flask-app-staging, with a remote of staging.
02:29
The next line deploys the application to it using git.
02:45
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.
03:02 You can use the Heroku CLI to create the pipeline.
03:09
This command creates a pipeline named realpython-flask-app and adds the app named realpython-flask-app as the production environment.
03:20
The next command seen on-screen will create a git remote that points this app, naming it prod.
03:36
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.
03:57
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 and 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.
04:29 Now that you have your applications and pipeline configured, you can use it to deploy your application to staging, review it there, and then promote it to production.
04:38
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.
04:54
As you can see, index() is now returning "This is yet another version!". You can deploy this new version to your staging environment by running the command seen on-screen.
05:07
These commands commit app.py, push the changes to the staging remote, and trigger the building and deployment process for this environment.
05:33 You should see the new version available at your staging app URL, and note that the production environment is still using the previous version.
05:43 When you’re happy with the changes, you can promote the new version to production using the Heroku CLI, the command seen on-screen.
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.
06:27 In the next section of the course, you’ll learn another important skill: how to manage settings and secrets for different environments.
Become a Member to join the conversation.
grogu on Nov. 27, 2022
If anyone has issues where their text doesn’t show in the heroku app url under the Application Deployment to Heroku section then this is what I did to fix the issue.
I know this is an older article ,but in case anyone runs into an issue where the return message “Hello this is the new version” doesn’t show in the Heroku app url ,I found that updating flask to the newest version fixed it. My flask version was at 1.1.2 and I changed the version to 2.2.2. I then re-deployed to Heroku and it showed the message. Hopefully this will help.