Full operating systems that are recommended by the FSF because they are exclusively free software. Hardware that supports free software Get information about hardware support for free software. Knowing which hardware devices support GNU/Linux is important ...

Free software resources

Trading options is the process of buying and selling stocks at a pre-negotiated price by a certain date. Options are a type of contract that gives the trader the right to buy or sell a particular ...

Best Options Trading Software

This guide will cover everything from how being a software affiliate marketer works, how you stand to profit from getting involved, and how to choose the best software affiliate programs available. Software affiliate networks connect publishers with ...

Software Affiliate Programs (2022)

The cybersecurity experts at Cybernews conducted thorough hands-on tests on numerous services to uncover the best antivirus software in 2023. Besides our firsthand experiences, these selections merge insights from autonomous labs like AV-TEST, AV ...

Best antivirus software for 2023

The best video editing software gives you post-production control over your footage. With visual content constantly growing in popularity, these apps are essential for marketing a business ...

Best video editing software (2023): Video editors for Windows, Mac and more

However, there are many different types of scanning software available, and different document types available. The best scanning software will be able to cater for a range of different needs and ...

Best scanning software of 2023

Despite economic fears, Gartner predicts spending on software will increase 11% in 2023, up to $879 billion from $790 billion in 2022. Why? The answer is simple. No business can survive in today ...

Four Crucial Steps For Successful Software Implementation

When the Agile Manifesto came out in 2001, it stated that one of the 12 principles of agile software is that “the best architectures, requirements and designs emerge from self-organizing teams.”

Does Software Architecture Still Matter?

Commentary: Google's promise should push competing brands to step up, making more phones safer to use for the long haul. Mike Sorrentino is a Senior Editor for Mobile, covering phones, texting ...

Google's Pixel 8 Software Update Plan Could Help All Phone Buyers

Lauren Hansen Holznienkemper is a professional researcher and writer specializing in HR software and best practices. Cassie is a deputy editor, collaborating with teams around the world while ...

Best Performance Management Software (October 2023)

Heroku

heroku

 Wow, pnpm, You're Really Fast: How to Use It on Heroku

 Vaja, pnpm, sou molt ràpid: com utilitzar-lo a Heroku

Vaya, pnpm, eres muy rápido: cómo usarlo en Heroku

 وای، pnpm، شما واقعاً سریع هستید: نحوه استفاده از آن در Heroku

 וואו, pnpm, אתה ממש מהיר: איך להשתמש בו ב-Heroku

すごい、pnpm、本当に速いですね: Heroku での使い方

 Wah, pnpm, Anda Sungguh Pantas: Cara Menggunakannya pada Heroku

 Uau, pnpm, ești cu adevărat rapid: cum să-l folosești pe Heroku

 Wow, pnpm, Ju jeni vërtet i shpejtë: Si ta përdorni atë në Heroku

ว้าว pnpm คุณเร็วจริงๆ: วิธีใช้งานบน Heroku

 Wow, pnpm, U Hatlisa Hakunene: Ndlela Yo Yi Tirhisa Eka Heroku

 Voy, pnpm, siz juda tezsiz: uni Heroku-da qanday ishlatish kerak

Wow, pnpm, Bạn thực sự nhanh: Cách sử dụng nó trên Heroku

Custom Domains for HTTP/2 on Heroku — It's So easy!

Effortlessly Deploy Django Apps to the Cloud with GitHub Actions and Heroku

In our last two articles, we explored how to configure CI/CD for Heroku using Heroku pipelines. When viewing a pipeline within the Heroku dashboard, you can easily start a deployment or promote your code from one environment to the next with the click of a button. From the dashboard, you can monitor the deployment and view its progress. This all works really well, assuming that you have Heroku open in your browser. But, what if you wanted to do it all from Slack? Software engineers use a lot of apps at work. Throughout the day, we are constantly bouncing between Zoom meetings, Jira tasks, Slack conversations, GitHub, email, our calendar, and our IDE. This context switching can be exhausting and also lead to a lot of visual clutter on our monitors. Sometimes, it’s nice to just live in Slack, and that’s why many tools offer Slack integrations. With these Slack integrations, you can monitor various processes and even use shortcut commands to trigger actions. Heroku ChatOps, the Heroku Slack integration, allows you to start and monitor deployments directly from Slack. In this article, we’ll explore some of the Slack commands it offers. Getting Started If you’d like to follow along throughout this tutorial, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here, and you can create a GitHub account here. The demo app that we will use with our Heroku pipeline in this article is deployed to Heroku, and the code is hosted on GitHub. Create Our Heroku Pipeline We won’t go through the step-by-step process of creating a Heroku pipeline in this article. Refer to these articles for a walkthrough of creating a Heroku pipeline: How to create a Heroku pipeline with a staging and production app and a single main branch
How to create a Heroku pipeline with a staging and production app with a dev branch and a main branch You can also read the Heroku docs for Heroku pipelines. Configuring your Heroku pipeline includes the following steps: Create a GitHub repo.
Create a Heroku pipeline.
Connect the GitHub repo to the Heroku pipeline.
Add a staging app to the pipeline.
Add a production app to the pipeline. The other activities that you’ll see in those articles, such as configuring review apps, Heroku CI, or automated deployments are optional. In fact, for the purposes of this demo, I recommend not configuring automated deployments, since we’ll be using some Slack commands to start the deployments. When you’re done, you should have a Heroku pipeline that looks something like this: Connect to Slack Now that you have your Heroku pipeline created, it’s time for the fun part: integrating with Slack. You can install the Heroku ChatOps Slack app here. Clicking that link will prompt you to grant the Heroku ChatOps app permission to access your Slack workspace: After that, you can add the Heroku ChatOps app to any Slack channel in your workspace. After adding the app, type /h login and hit Enter. This will prompt you to connect your Heroku and GitHub accounts. You’ll see several Heroku OAuth and GitHub OAuth screens where you confirm connecting these accounts. (As a personal anecdote, I found that it took me several tries to connect my Heroku account and my GitHub account. It may be due to having several Slack workspaces to choose from, but I’m not sure.) After connecting your Heroku account and your GitHub account, you’re ready to start using Heroku in Slack. View All Pipelines To view all deployable pipelines, you can type /h pipelines: View Pipeline Info To see information about any given pipeline, type /h info <PIPELINE_NAME>. (Anything you see in angle brackets throughout this article should be replaced by an actual value. In this case, the value would be the name of a pipeline — for example, “heroku-flow-demo-pipeline”.) View Past Releases To view a history of past releases for any given pipeline, type /h releases <PIPELINE_NAME>. This command defaults to showing you past releases for the production app, so if you want to see the past releases for the staging app, you can type /h releases <PIPELINE_NAME> in <STAGE_NAME>, where <STAGE_NAME> is “staging.” Deploy to Staging Now that we know which pipelines are available, we can see information about any given pipeline along with when the code was last released for that pipeline. We’re ready to trigger a deployment. Most engineering organizations have a Slack channel (or channels) where they monitor deployments. Imagine being able to start a deployment right from that channel and monitor it as it goes out! That’s exactly what we’ll do next. To start a deployment to your staging environment, type /h deploy <PIPELINE_NAME> to <STAGE_NAME>, where <STAGE_NAME> is “staging.” After running that command, an initial message is posted to communicate that the app is being deployed. Shortly after, you’ll also see several more messages; this time, in a Slack thread on the original message: If you want to verify what you’re seeing in Slack, you can always check the Heroku pipeline in your Heroku dashboard. You’ll see the same information: The staging app has been deployed! Promote to Production Now, let’s promote our app to production. Without the Slack commands, we could navigate to our Heroku pipeline, click the “Promote to production” button, and then confirm that action in the modal dialog that appears. However, we’d prefer to stay in Slack. To promote the app to production from Slack, type /h promote <PIPELINE_NAME>. Just like with the staging deployment, an initial Slack message will be sent, followed by several other messages as the production deployment goes out: And — voilà — the latest changes to the app are now in production! Conclusion Now, you can start and monitor Heroku app deployments all from Slack — no need to context switch or move between multiple apps. For more use cases and advanced setups, you can also check out the docs. Happy deploying! In our last two articles, we explored how to configure CI/CD for Heroku using Heroku pipelines . When viewing a pipeline within the Heroku dashboard, you can easily start a deployment or promote your code from one environment to the next with the click of a button. From the dashboard, you can monitor the deployment and view its progress. configure CI/CD for Heroku using Heroku pipelines start a deployment or promote your code from one environment to the next This all works really well, assuming that you have Heroku open in your browser. But, what if you wanted to do it all from Slack? Software engineers use a lot of apps at work. Throughout the day, we are constantly bouncing between Zoom meetings, Jira tasks, Slack conversations, GitHub, email, our calendar, and our IDE. This context switching can be exhausting and also lead to a lot of visual clutter on our monitors. Sometimes, it’s nice to just live in Slack, and that’s why many tools offer Slack integrations. With these Slack integrations, you can monitor various processes and even use shortcut commands to trigger actions. Heroku ChatOps , the Heroku Slack integration, allows you to start and monitor deployments directly from Slack. In this article, we’ll explore some of the Slack commands it offers. Heroku ChatOps Getting Started If you’d like to follow along throughout this tutorial, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here , and you can create a GitHub account here . create a Heroku account here create a GitHub account here The demo app that we will use with our Heroku pipeline in this article is deployed to Heroku, and the code is hosted on GitHub . the code is hosted on GitHub Create Our Heroku Pipeline We won’t go through the step-by-step process of creating a Heroku pipeline in this article. Refer to these articles for a walkthrough of creating a Heroku pipeline: How to create a Heroku pipeline with a staging and production app and a single main branch How to create a Heroku pipeline with a staging and production app with a dev branch and a main branch How to create a Heroku pipeline with a staging and production app and a single main branch How to create a Heroku pipeline with a staging and production app and a single main branch How to create a Heroku pipeline with a staging and production app with a dev branch and a main branch How to create a Heroku pipeline with a staging and production app with a dev branch and a main branch You can also read the Heroku docs for Heroku pipelines . Heroku docs for Heroku pipelines Configuring your Heroku pipeline includes the following steps: Create a GitHub repo. Create a Heroku pipeline. Connect the GitHub repo to the Heroku pipeline. Add a staging app to the pipeline. Add a production app to the pipeline. Create a GitHub repo. Create a Heroku pipeline. Connect the GitHub repo to the Heroku pipeline. Add a staging app to the pipeline. Add a production app to the pipeline. The other activities that you’ll see in those articles, such as configuring review apps, Heroku CI, or automated deployments are optional. In fact, for the purposes of this demo, I recommend not configuring automated deployments, since we’ll be using some Slack commands to start the deployments. not When you’re done, you should have a Heroku pipeline that looks something like this: Connect to Slack Now that you have your Heroku pipeline created, it’s time for the fun part: integrating with Slack. You can install the Heroku ChatOps Slack app here . install the Heroku ChatOps Slack app here Clicking that link will prompt you to grant the Heroku ChatOps app permission to access your Slack workspace: After that, you can add the Heroku ChatOps app to any Slack channel in your workspace. After adding the app, type /h login and hit Enter. This will prompt you to connect your Heroku and GitHub accounts. You’ll see several Heroku OAuth and GitHub OAuth screens where you confirm connecting these accounts. /h login (As a personal anecdote, I found that it took me several tries to connect my Heroku account and my GitHub account. It may be due to having several Slack workspaces to choose from, but I’m not sure.) (As a personal anecdote, I found that it took me several tries to connect my Heroku account and my GitHub account. It may be due to having several Slack workspaces to choose from, but I’m not sure.) After connecting your Heroku account and your GitHub account, you’re ready to start using Heroku in Slack. View All Pipelines To view all deployable pipelines, you can type /h pipelines : /h pipelines View Pipeline Info To see information about any given pipeline, type /h info <PIPELINE_NAME> . (Anything you see in angle brackets throughout this article should be replaced by an actual value. In this case, the value would be the name of a pipeline — for example, “heroku-flow-demo-pipeline”.) /h info <PIPELINE_NAME> View Past Releases To view a history of past releases for any given pipeline, type /h releases <PIPELINE_NAME> . /h releases <PIPELINE_NAME> This command defaults to showing you past releases for the production app, so if you want to see the past releases for the staging app, you can type /h releases <PIPELINE_NAME> in <STAGE_NAME> , where <STAGE_NAME> is “staging.” /h releases <PIPELINE_NAME> in <STAGE_NAME> <STAGE_NAME> Deploy to Staging Now that we know which pipelines are available, we can see information about any given pipeline along with when the code was last released for that pipeline. We’re ready to trigger a deployment. Most engineering organizations have a Slack channel (or channels) where they monitor deployments. Imagine being able to start a deployment right from that channel and monitor it as it goes out! That’s exactly what we’ll do next. To start a deployment to your staging environment, type /h deploy <PIPELINE_NAME> to <STAGE_NAME> , where <STAGE_NAME> is “staging.” /h deploy <PIPELINE_NAME> to <STAGE_NAME> <STAGE_NAME> After running that command, an initial message is posted to communicate that the app is being deployed. Shortly after, you’ll also see several more messages; this time, in a Slack thread on the original message: If you want to verify what you’re seeing in Slack, you can always check the Heroku pipeline in your Heroku dashboard. You’ll see the same information: The staging app has been deployed! Promote to Production Now, let’s promote our app to production. Without the Slack commands, we could navigate to our Heroku pipeline, click the “Promote to production” button, and then confirm that action in the modal dialog that appears. However, we’d prefer to stay in Slack. could To promote the app to production from Slack, type /h promote <PIPELINE_NAME> . /h promote <PIPELINE_NAME> Just like with the staging deployment, an initial Slack message will be sent, followed by several other messages as the production deployment goes out: And — voilà — the latest changes to the app are now in production! Conclusion Now, you can start and monitor Heroku app deployments all from Slack — no need to context switch or move between multiple apps. For more use cases and advanced setups, you can also check out the docs . check out the docs Happy deploying!

Heroku for ChatOps: How to Start and Monitor Deployments From Slack

Enhancing Application Stability and Security with Heroku Logplex

In the previous article in this series, we looked at how we could automate deploys to Heroku using Heroku Flow for our CI/CD. That setup had two Heroku apps for staging and production but only used a single main branch. The staging app was automatically deployed when you committed to the main branch, and the production app was manually deployed by clicking the “Promote to production” button in the Heroku pipeline. That strategy assumes that you’re doing “trunk-based development,” in which you commit to a single main branch in your code repo. However, some engineering teams still follow a branching strategy called Gitflow, which involves using a dev branch and a main branch. Feature branches are merged into the dev branch to deploy code to a staging environment and on a regular cadence, the dev branch is merged into the main branch to release the code to the production environment. In this article, we’ll consider how we can configure Heroku Flow to meet our CI/CD needs when following the Gitflow branching strategy. We’ll use our Heroku Pipeline to deploy our app to our staging environment when we push to the dev branch and deploy our app to our production environment when we push it to the main branch. Ready to go with the flow? Getting Started If you’d like to follow along throughout this tutorial, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here, and you can create a GitHub account here. The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub. Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-gitflow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’re going to create a Heroku pipeline that includes two apps: a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Nice work! Creating Our Staging and Production Apps As we mentioned, we’ll use two environments for our app: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. The production environment is where code is released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the Staging section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s dev branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. In the dialog that appears, make sure the dev branch is targeted, and check the box to “Wait for CI to pass before deploy.” In a later step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. Now let’s do the same thing for the production app, but this time choosing to deploy our production app whenever we commit code to the main branch. Enabling Heroku CI If we’re going to require CI to pass, we had better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps which get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to manually review your changes. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine to run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables review apps to be automatically created for each PR.
The second box ensures that the review app isn’t created until CI passes.
The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline.
We created a staging app and a production app for that pipeline.
We enabled automatic deploys from the dev branch to our staging app.
We enabled automatic deploys from the main branch to our production app.
We enabled Heroku CI to run tests for every PR.
We enabled the creation of Heroku review apps for every PR. Now, let’s see it all in action! Create a feature branch off of your dev branch with any code change you’d like, and then use that to create a PR in GitHub to merge that feature branch into dev. I made a very minor UI change, updating the heading text from “Heroku Flow Gitflow Demo” to “Heroku Flow Gitflow Branching”. Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your Tests tab: After the CI pipeline passes, you’ll note that another piece of info gets appended to your PR in GitHub. The review app is deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that Heroku automatically deployed the staging app since new code was committed to the dev branch. At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users in production. You can create another PR to merge the dev branch into the main branch, or you can do this from your terminal by checking out the main branch and then running git merge dev and git push. Once you’ve committed these changes to the main branch, look at your Heroku pipeline again, and you’ll see that the production app was automatically deployed. And with that, your changes are now in production for all your users to see. Way to go! Conclusion If you’ve followed along this far, give yourself a pat on the back. Walking through these steps, we’ve configured everything we need for an enterprise-ready CI/CD solution for a team using the Gitflow branching strategy and multiple environments. It doesn’t matter if you prefer trunk-based development or Gitflow as your branching strategy — Heroku Flow can support either. Now not only can you host your apps on Heroku, but you can set up all of your CI/CD infrastructure on Heroku’s platform as well. In the previous article in this series, we looked at how we could automate deploys to Heroku using Heroku Flow for our CI/CD . That setup had two Heroku apps for staging and production but only used a single main branch. The staging app was automatically deployed when you committed to the main branch, and the production app was manually deployed by clicking the “Promote to production” button in the Heroku pipeline. using Heroku Flow for our CI/CD main main That strategy assumes that you’re doing “ trunk-based development ,” in which you commit to a single main branch in your code repo. trunk-based development main However, some engineering teams still follow a branching strategy called Gitflow , which involves using a dev branch and a main branch. Feature branches are merged into the dev branch to deploy code to a staging environment and on a regular cadence, the dev branch is merged into the main branch to release the code to the production environment. Gitflow dev main dev dev main In this article, we’ll consider how we can configure Heroku Flow to meet our CI/CD needs when following the Gitflow branching strategy. We’ll use our Heroku Pipeline to deploy our app to our staging environment when we push to the dev branch and deploy our app to our production environment when we push it to the main branch. Heroku Flow dev main Ready to go with the flow? Getting Started If you’d like to follow along throughout this tutorial, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here , and you can create a GitHub account here . create a Heroku account here create a GitHub account here The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub . the code is hosted on GitHub Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-gitflow-demo
$ npm install
$ npm start $ cd heroku-flow-gitflow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: http://localhost:5001/ Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’re going to create a Heroku pipeline that includes two apps: a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Nice work! Creating Our Staging and Production Apps As we mentioned, we’ll use two environments for our app: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. The production environment is where code is released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the Staging section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s dev branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. dev In the dialog that appears, make sure the dev branch is targeted, and check the box to “Wait for CI to pass before deploy.” In a later step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. dev Now let’s do the same thing for the production app, but this time choosing to deploy our production app whenever we commit code to the main branch. main Enabling Heroku CI If we’re going to require CI to pass, we had better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! npm test app.json Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps which get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to manually review your changes. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine to run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables review apps to be automatically created for each PR. The second box ensures that the review app isn’t created until CI passes. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. The first box enables review apps to be automatically created for each PR. The second box ensures that the review app isn’t created until CI passes. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline. We created a staging app and a production app for that pipeline. We enabled automatic deploys from the dev branch to our staging app. We enabled automatic deploys from the main branch to our production app. We enabled Heroku CI to run tests for every PR. We enabled the creation of Heroku review apps for every PR. We created a Heroku pipeline. We created a staging app and a production app for that pipeline. We enabled automatic deploys from the dev branch to our staging app. dev We enabled automatic deploys from the main branch to our production app. main We enabled Heroku CI to run tests for every PR. We enabled the creation of Heroku review apps for every PR. Now, let’s see it all in action! Create a feature branch off of your dev branch with any code change you’d like, and then use that to create a PR in GitHub to merge that feature branch into dev . I made a very minor UI change, updating the heading text from “Heroku Flow Gitflow Demo” to “Heroku Flow Gitflow Branching”. dev dev Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your Tests tab: After the CI pipeline passes, you’ll note that another piece of info gets appended to your PR in GitHub. The review app is deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that Heroku automatically deployed the staging app since new code was committed to the dev branch. dev At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users in production. You can create another PR to merge the dev branch into the main branch, or you can do this from your terminal by checking out the main branch and then running git merge dev and git push . dev main main git merge dev git push Once you’ve committed these changes to the main branch, look at your Heroku pipeline again, and you’ll see that the production app was automatically deployed. main And with that, your changes are now in production for all your users to see. Way to go! Conclusion If you’ve followed along this far, give yourself a pat on the back. Walking through these steps, we’ve configured everything we need for an enterprise-ready CI/CD solution for a team using the Gitflow branching strategy and multiple environments. It doesn’t matter if you prefer trunk-based development or Gitflow as your branching strategy — Heroku Flow can support either. Now not only can you host your apps on Heroku, but you can set up all of your CI/CD infrastructure on Heroku’s platform as well.

Go With the CI/CD Flow: Using Heroku Flow With Gitflow Branching

The Heroku team has long been an advocate of CI/CD. Their platform integrates with many third-party solutions like GitLab CI/CD or GitHub Actions. In a previous article, I demonstrated how you can configure your Heroku app with GitLab CI/CD to automatically deploy your app to production. In a follow-up article, I walked you through a slightly more nuanced setup involving both a staging environment and a production environment. But if you want to go all in on Heroku, you can use a series of solutions called Heroku Flow to configure all your CI/CD without any third parties. Heroku Flow brings together Heroku pipelines, Heroku CI, Heroku review apps, a GitHub integration, and a release phase. In this article, I’ll show you how to set this up for your own projects. Getting Started Before we begin, if you’d like to follow along, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here, and you can create a GitHub account here. The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub. Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’ll create a Heroku pipeline that includes a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Well done! Creating Our Staging and Production Apps Most engineering organizations use at least two environments: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. Code in the staging environment is then promoted to the production environment to be released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the “Staging” section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now, let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s main branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. In the dialog that appears, make sure the main branch is targeted, and check the box to “Wait for CI to pass before deploy.” In our next step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. Enabling Heroku CI If we’re going to require CI to pass, we better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case, because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps that get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to review your changes manually. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine and run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables the automatic creation of review apps for each PR.
The second box ensures that CI must pass before the review app can be created.
The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline.
We created a staging app and a production app for that pipeline
We enabled automatic deploys for our staging app
We enabled Heroku CI to run tests for every PR
We enabled Heroku review apps to be created for every PR Now, let’s see it all in action. Create a PR in GitHub with any code change you’d like. I made a very minor UI change, updating the heading text from “Heroku Flow Demo” to “Heroku Flow Rules!” Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your “Tests” tab: After the CI pipeline passes, you’ll note another piece of info gets appended to your PR in GitHub. The review app gets deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes in it. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that the staging app was automatically deployed since new code was committed to the main branch. At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users. Click the “Promote to production” button on the staging app. This will open a dialog for you to confirm your action. Click “Promote” to confirm your changes. After promoting the code, you’ll see the production app being deployed. And with that, your changes are now in production for all of your users to enjoy. Nice work! Conclusion What a journey we’ve been through! In this short time together, we’ve configured everything we need for an enterprise-ready CI/CD solution. If you’d like to use a different CI/CD tool like GitLab CI/CD, GitHub Actions — or whatever else you may prefer — Heroku supports that as well. But if you don’t want to reach out to a third-party CI/CD provider, you can now do it all within Heroku with Heroku Flow. The Heroku team has long been an advocate of CI/CD. Their platform integrates with many third-party solutions like GitLab CI/CD or GitHub Actions. In a previous article , I demonstrated how you can configure your Heroku app with GitLab CI/CD to automatically deploy your app to production. In a follow-up article , I walked you through a slightly more nuanced setup involving both a staging environment and a production environment. previous article follow-up article But if you want to go all in on Heroku, you can use a series of solutions called Heroku Flow to configure all your CI/CD without any third parties. Heroku Flow brings together Heroku pipelines, Heroku CI, Heroku review apps, a GitHub integration, and a release phase. configure all your CI/CD In this article, I’ll show you how to set this up for your own projects. Getting Started Before we begin, if you’d like to follow along, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here , and you can create a GitHub account here . create a Heroku account here create a GitHub account here The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub . the code is hosted on GitHub Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-demo
$ npm install
$ npm start $ cd heroku-flow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: http://localhost:5001/ Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’ll create a Heroku pipeline that includes a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Well done! Creating Our Staging and Production Apps Most engineering organizations use at least two environments: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. Code in the staging environment is then promoted to the production environment to be released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the “Staging” section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now, let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s main branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. main In the dialog that appears, make sure the main branch is targeted, and check the box to “Wait for CI to pass before deploy.” In our next step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. main Enabling Heroku CI If we’re going to require CI to pass, we better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case, because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! npm test app.json Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps that get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to review your changes manually. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine and run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables the automatic creation of review apps for each PR. The second box ensures that CI must pass before the review app can be created. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. The first box enables the automatic creation of review apps for each PR. The second box ensures that CI must pass before the review app can be created. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline. We created a staging app and a production app for that pipeline We enabled automatic deploys for our staging app We enabled Heroku CI to run tests for every PR We enabled Heroku review apps to be created for every PR We created a Heroku pipeline. We created a staging app and a production app for that pipeline We enabled automatic deploys for our staging app We enabled Heroku CI to run tests for every PR We enabled Heroku review apps to be created for every PR Now, let’s see it all in action. Create a PR in GitHub with any code change you’d like. I made a very minor UI change, updating the heading text from “Heroku Flow Demo” to “Heroku Flow Rules!” Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your “Tests” tab: After the CI pipeline passes, you’ll note another piece of info gets appended to your PR in GitHub. The review app gets deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes in it. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that the staging app was automatically deployed since new code was committed to the main branch. main At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users. Click the “Promote to production” button on the staging app. This will open a dialog for you to confirm your action. Click “Promote” to confirm your changes. After promoting the code, you’ll see the production app being deployed. And with that, your changes are now in production for all of your users to enjoy. Nice work! Conclusion What a journey we’ve been through! In this short time together, we’ve configured everything we need for an enterprise-ready CI/CD solution. If you’d like to use a different CI/CD tool like GitLab CI/CD, GitHub Actions — or whatever else you may prefer — Heroku supports that as well. But if you don’t want to reach out to a third-party CI/CD provider, you can now do it all within Heroku with Heroku Flow. do it all

How I Got My CI/CD Act together With Heroku Flow

How To Cache RESTful API Requests for Redis With Heroku Data

Location, Location, Location! PostGIS and Heroku Postgres

অবস্থান, অবস্থান, অবস্থান! পোস্টজিআইএস এবং হেরোকু পোস্টগ্রেস

Lage, Lage, Lage! PostGIS und Heroku Postgres

¡Ubicación, ubicación, ubicación! PostGIS y Heroku Postgres

Emplacement, emplacement, emplacement ! PostGIS et Heroku Postgres

स्थान, स्थान, स्थान! PostGIS और Heroku Postgres

場所、場所、場所！PostGIS と Heroku Postgres

위치, 위치, 위치! PostGIS와 Heroku Postgres

Localização, localização, localização! PostGIS e Heroku Postgres

Местоположение, Расположение, Местоположение! PostGIS и Heroku Postgres

Konum, Konum, Konum! PostGIS ve Heroku Postgres

Vị trí, vị trí, vị trí! PostGIS và Heroku Postgres

位置，位置，位置！PostGIS 和 Heroku Postgres

In a , we explored how to automate deployments to Heroku using GitLab CI/CD. That setup deployed the app to its production environment every time we pushed code to the branch. previous article main In this article, we’ll consider a slightly more nuanced approach: What if we have multiple environments? Most engineering organizations use at least three environments: a local development environment, a staging environment, and a production environment. Additionally, some engineering teams follow a , where they have a branch and a branch. This strategy has since fallen out of favor and been replaced by , but it’s not uncommon to find organizations still following this practice. Gitflow branching strategy dev main trunk-based development Today, we will look at how to configure GitLab CI/CD to deploy our app to our staging environment when we push to the branch and deploy our app to our production environment when we push it to the branch. dev main Getting Started Before we begin, we’ll need two things: a Heroku account and a GitLab account. Heroku is a great place to host and deploy your apps. As a platform as a service (PaaS), Heroku allows you to focus on building cool things while abstracting away much of the infrastructure complexity. You can . create a Heroku account here GitLab is a great place to store your code. Beyond just being a source code management tool, GitLab also offers native CI/CD capabilities so you can set up pipelines to test and deploy your code without requiring another third-party tool. You can . create a GitLab account here The demo app shown in this article uses both GitLab and Heroku. You can . find all the code in the GitLab repo here Running Our App Locally You can run the app locally by cloning the repo, installing dependencies, and running the start command. In your terminal, do the following: $ git clone https://gitlab.com/tylerhawkins1/heroku-gitflow-staging-production-gitlab-cicd-demo.git
$ cd heroku-gitflow-staging-production-gitlab-cicd-demo
$ npm install
$ npm start After starting the app, visit in your browser, and you’ll see the app running locally: http://localhost:5001/ Deploying Our App to Heroku Now that the app is running locally let’s deploy it to Heroku so that you can access it anywhere, not just on your machine. Remember that we are going to deploy your app to both a staging environment and a production environment. That means that we’ll have two Heroku apps based on the same GitLab repo. If you don’t already have the installed on your machine, you’ll need to install it before moving on. Heroku CLI After installing the Heroku CLI, run the following commands from your terminal to check out the branch, create a new production Heroku app, deploy it to your production environment, and open it in your browser: main $ git checkout main
$ heroku create heroku-gitlab-ci-cd-production --remote heroku-production
$ git push heroku-production main
$ heroku open --remote heroku-production With that, you should see the same app, but this time running on a Heroku URL instead of on localhost. Nice work — you’ve deployed your Heroku app to production! But we’re not done yet. We also need to configure and deploy your staging app. To do this, run this similar set of commands shown below: $ git checkout dev
$ heroku create heroku-gitlab-ci-cd-staging --remote heroku-staging
$ git push heroku-staging main
$ heroku open --remote heroku-staging Now, you’ll have the same app deployed again, but this time to a different URL that will serve as your staging environment. Now we have both of your environments configured! Note the differences and similarities between the commands for the production app and the staging app: The production app uses the branch and the staging app uses the branch. main dev The production app is called , and the staging app is called . heroku-gitlab-ci-cd-production heroku-gitlab-ci-cd-staging The production app’s git remote is called , and the staging app’s git remote is called . heroku-production heroku-staging Both the production app and the staging app’s git remotes use a branch since . main Heroku only deploys the app when code is pushed to its main branch Keep in mind that branch is different from set of and branches. The branch that you’re pushing to here is the branch on your git remote — in this case, Heroku. this main your main dev main main So when you’re on your local branch and run , you’re pushing your branch to the Heroku production app’s branch. And when you’re on your local branch and run , you’re pushing your branch to the Heroku staging app’s branch. main git push heroku-production main main main dev git push heroku-staging main dev main Making Changes to Our App Now that we have our Heroku app up and running, what if we want to make some changes? Following a rough approximation of the Gitflow branching strategy, we could do the following: Check out the branch dev Make changes to the code Add, commit, and push those changes to the branch dev Deploy those changes to the staging Heroku app by running git push heroku-staging main Check out the branch main Merge the branch into the branch dev main Deploy those changes to the production Heroku app by running git push heroku-production main (If we were truly following Gitflow, we’d have created a feature branch to merge into , and a release branch to merge into , but we’ve omitted those steps to keep things simple.) dev main Now, wouldn’t it be nice if we could automate the deployment to either of our environments instead of having to deploy them manually all the time? This is where GitLab CI/CD comes into play. Continuous Integration / Continuous Deployment Continuous integration (CI) is all about committing often and keeping the build in a good state at all times. Typically you would verify that the build is in a good state by running checks in a CI pipeline. These checks might include linters, unit tests, and/or end-to-end tests. Continuous deployment (CD) is all about deploying frequently. If the checks in the CI pipeline pass, then the build gets deployed. If the checks in the CI pipeline fail, then the build does not get deployed. With GitLab CI/CD, we can configure our CI pipeline to do exactly this — run our tests and then deploy our app to Heroku if the tests all pass. Most importantly, for our setup, we can configure rules within our CI pipeline to specify where the app should be deployed. Configuring GitLab CI/CD We can create a CI pipeline in GitLab programmatically using a file. Our file looks like this: .gitlab-ci.yml image: node:20.10.0

cache:
  paths:
    - node_modules/

before_script:
  - node -v
  - npm install

stages:
  - test
  - deploy

unit-test-job:
  stage: test
  script:
    - npm test

deploy-job:
  stage: deploy
  variables:
    HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
    - if: $CI_COMMIT_REF_NAME =~ /dev/
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_STAGING
  script:
    - apt-get update -yq
    - apt-get install -y ruby-dev
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY GitLab CI pipelines consist of stages and jobs. Each stage can contain one or more jobs. In our pipeline, we have two stages: and . In the stage, we run our unit tests in the . In the stage, we deploy our app to Heroku in the . test deploy test unit-test-job deploy deploy-job We can only progress to the next stage if all the jobs in the previous stage pass. That means if the unit tests fail, then the app won’t be deployed, which is a good thing! We wouldn’t want to deploy our app if it was in a bad state. You’ll note that the stage has a section with some conditional logic in place. This is where we specify to which environment our app should be deployed. If we’re on the branch, then we deploy our production app. If we’re on the branch, then we deploy our staging app. deploy rules main dev You’ll also note that the stage references several variables called , , and . These are stored as . deploy $HEROKU_APP_NAME_PRODUCTION $HEROKU_APP_NAME_STAGING $HEROKU_API_KEY CI/CD variables within GitLab If you’re setting this up in your own GitLab account, you’ll need to first find your API key in your Heroku account. Within your Heroku account settings, you should see a section for your API key. If you haven’t generated an API key yet, generate one now. Next, in your GitLab project, click on > > . Expand that section and add three new variables: Settings CI/CD Variables The value for will be the API key from your Heroku account. $HEROKU_API_KEY The value for will be the name of your production Heroku app. My production app’s name is , but since Heroku app names are universally unique, yours will be something different. $HEROKU_APP_NAME_PRODUCTION heroku-gitlab-ci-cd-production The value for will be the name of your staging Heroku app. My staging app’s name is . Again, since Heroku app names are universally unique, yours will be something different. $HEROKU_APP_NAME_STAGING heroku-gitlab-ci-cd-staging With that, your GitLab CI pipeline is ready to go! Let’s test it out. Deploying Our Heroku App to the Staging Environment Let’s check out the branch and make a change to the code in our app. I made a simple change to the heading text and added several new lines to the text in the UI. You can make a similar change in your code. dev Now, add, commit, and push that change to the branch. This will start the GitLab CI pipeline. You can view the pipeline within GitLab and see the progress in real-time. dev If everything goes well, you should see that both the and stages have passed. Now, go check out your hosted Heroku app at the staging environment URL. The GitLab CI pipeline took care of deploying the app for you, so you’ll now see your changes live in the staging environment! test deploy With a staging environment set up, you now have a great place to manually test your code in a hosted environment. This is also a perfect spot for QA testers or product managers to verify changes before they go to production. Now, check out your production app URL. You’ll note that it’s still showing the old UI without the most recent changes. This is because the GitLab CI pipeline only deployed the changes to the staging environment, not the production environment. We’ve verified that the code looks good in our staging environment, so let’s promote it to our production environment. Deploying Our Heroku App to the Production Environment Let’s check out the branch and then merge the branch into your branch. You could do this through a pull request or by running and then . main dev main git merge dev git push This will start the GitLab CI pipeline once again, but this time, it will be preparing to deploy your production app. You can also view all the pipeline runs on the Pipelines page in GitLab to see the various builds for your and branches: dev main Once the pipeline finishes, visit the URL for your production Heroku app. You should now see your changes also deployed in production. Great work! Conclusion A good CI pipeline allows you to ship new features quickly and confidently without manually managing the deployment process. Having multiple environments configured for local development, staging, and production gives you more control over where and when code is released. Heroku and GitLab CI/CD allow you to automate all of this to make your DevOps processes a breeze! Also published . here

Stories, News & Mentions about HEROKU

Heroku’s Stories on HackerNoon

Heroku's News & Mentions