Let’s Build a Continuous Delivery and Branching Process with Github Actions, Vercel and Heroku
For JavaScript Apps (Part 2/2)
This publication is a continuation of Building a Continuous Delivery + Branching Process with Github Actions, Vercel and Heroku for JavaScript Applications [EP. 1/2], where we modeled a workflow for the Continuous Delivery of the project’s web stack used in the examples. If you haven’t read the previous post, I suggest you read it.
Recap and objectives
In the previous post, I describe the objectives and motivations for this strategy.
We will model a process that permeates the project’s branching activities, creating an isolated and secure preview in the cloud.
We added the deployment-step job, setting the VUE_APP_API environment variable with a dynamic API URL according to the branch we are currently working on.
Now we will finish the entire workflow by applying a deployment-step job also in the API, generating the dynamic URL for our application hosted on Heroku.
Adding the Deployment Job to Heroku
As in the last post, I will split this topic into two parts.
First, we’ll get the secrets needed for the action’s inputs.
We’ll add to deployment-step, secrets to required inputs. Afterwards, we will make the declaration of the branch that the action will respond by and we will build the dynamic URL.
The sample repository can be accessed by clicking on the link below:
Searching for secrets and adding to Github Secrets
Access the application settings address in Heroku Dashboard and click “Create Authorization” to generate an authorization token. With it, the action will have access to handling applications within our account.
After that, go to the tab “secrets” under “settings” in our repository on Github for adding the new secret variables.
Let’s name the newly generated token HEROKU_API_KEY and HEROKU_EMAIL the email that is registered in our Heroku account.
Adding the job to the workflow
The workflow below can be found in the file inside the monorepo root at .github/workflows/pipeline-server.yml.
From line 32 on, there is the deployment-step job. In this job we will apply the script for Continuous Delivery with dynamic URL generation and synchronized with the web workflow.
Before proceeding, even though it is listed in the references, the link to the action responsible for the Heroku integration task is right below.
As in the last post, I state in line 34 that deployment-step requires test-routine to complete successfully to start.
I again use the rlespinasse/github-slug-action action to create a slug version of the environment variables provided in context by Github Actions.
In “with” on line 42, I add the secrets we just saved to the mandatory inputs “heroku_api_key” and “heroku_email”.
In line 46 in the “branch” input, I declare from which branch the artifact will be generated. I use the context “github.ref” provided also by Github Actions for the purpose.
The magic happens in “heroku_app_name” on line 44. I declare the dynamic API URL the same way I created the environment variable in VUE_APP_API in the last post, fleshing out the strategy.
In short, every time we branch out for development, the rlespinasse/github-slug-action action will provide its slug version. Finally, the appropriate Heroku application will be created or updated with that address.
Example: If the branch name is feat/cd, then the generated URL will be https://pedromoraisf-monoyarn-feat-cd.herokuapp.com.
Viewing results
Making some change in the server folder and sending it to the repository on Github, the pipeline starts the configured process.
By clicking on the address of line 113 of the generated output, we can see our artifact in production.
Now we can smoothly develop features on the web stack that communicate with the API, and the addresses will match normally — both in branching and in production artifact.
Conclusion
Finishing these two episodes, we have a complete Continuous Delivery environment with Branching using Github Actions, Vercel and Heroku.
We gain from automating reliable previews in branching, which can be used both as a quick approval and extended development of some critical feature.
References
More content at plainenglish.io
