Deployment preview using Google Cloud Run
Streamline your feature deployment process today!
In NE Digital every feature goes through a project life cycle flow. In this flow, the two essential steps are the design QA (to make sure the feature is pixel perfect) and the product QA (to verify all business use cases) after deployment. Traditionally, we would deploy our changes in a UAT environment before we began the QA process. The QA process often surfaced various small changes to make sure the feature is pixel perfect. This typically resulted in back and forth action for the developer and highlighted the opportunity to create more efficiencies in the release process.
Our solution was to create a process that would allow developers, designers and business users to use an intermediate environment as a collaborative space to identify issues early and ensure that the final feature that would be deployed would be near-perfect. We named this bridge process, where a developer could share a preview of their changes before merging and deploying to the UAT environment, a deployment preview.
In this article, we will discuss the following key points in detail:
Architecture
To implement a deployment preview we are using google cloud run as our infrastructure solution. Google cloud run is similar to AWS lambda. It’s cost-effective, pay as you use. An illustration of the architecture of a simple application build using NodeJs is below:
The Chrome icon represents a user who is accessing our NodeJs service inside the google cloud run and then calling external services for related data.
Once a service is deployed, the cloud run will autoscale a service when load increases just like in Kubernetes.
Setup
Setting a new service in the google cloud run is pretty straight forward. Let’s discuss each step in brief using snapshots.
The first step is to select a region for your service. If you are located in Singapore than asia-asoutheast1 should be the region for your service else there will be unnecessary delay due to RTT(Round trip time). Along with that, we need to specify the name of our service.
The second step is to provide a container image URL from a docker registry where you keep your docker images like DockerHub, Google container registry, Azure registry, etc
Make sure your cloud run has access to your registry to get your container image.
The third step allows you to do an advance setting as mentioned in the diagram below for three main sections.
a) Container: In this section, we define the configuration related to a docker container like a container port or a default port which we expose in the docker image. The other settings below are related to container commands and arguments which are not relevant at this stage.
b) Variables: In the variable section, we can define all environment variables required to run your service. In the case of any secured API key or token, you can use the secret manager to store sensitive information as highlighted in the image.
c) Connections: In the connection tab, you can specify the Cloud SQL connection string to enable your service to connect to SQL. Also if you have any external network which you want to access privately in that case you can create a VPC(Virtual Private Connection) and add it here. All request from your service to the external network will be routed via this VPC.
On clicking next it will start creating your service like this. First, it will create the service and if it’s up and running then it starts routing the traffic.
Once traffic is routed a static URL will be assigned to our service.
The final step is to create a preview for your service which means if you deploy to another version you should be able to preview the same before routing the traffic to it. You can generate multiple previews in the google cloud run. To do this you need to add a tag for a version as mentioned below and click save.
Now we have a URL associated with our new change, where the tag was added as a prefix to your service URL. If the tag for your change is preview than URL format will be likehttps://{tag}---{service-url}
Release flow
In the previous steps, we have created our service in google cloud run and added a preview for one of the versions manually. How do we use this approach to deploy a new version and dynamically generate a preview URL to share with others for the QA process?
To address this we will use bitbucket pipeline to deploy our application to google cloud run and dynamically generate preview URL.
If you are new to bitbucket pipeline and don’t know how to deploy an application using bitbucket pipeline I would recommend checking my previous article https://medium.com/ne-digital/deploy-nextjs-app-to-kubernetes-using-bitbucket-pipeline-3c152b742b0a
You can use any application for the deployment preview, in this example, we are using NextJs. We have a pipeline flow to build a NextJs application and later use that in package step to create a docker container. You can use google cloud image for this step as it will provide access to all gcloud related commands. Once docker image is ready we will push it to GCR(google container registry).
gcloud beta run deploy demo-service --image IMAGE_URL --no-traffic --tag TAG_NAME
Before executing this command replace the following attributes.
- IMAGE_URL with the URL for your image
- TAG_NAME with your lower-case tag name
The tag allows you to directly test the new revision at a specific URL, without serving traffic. The URL starts with the tag name you provided: for example if you used the tag name green on the service demo-service, you would test the tagged revision at the URL https://green---demo-service-abcdef.a.run.app
This is the final code snippet to deploy your service with a preview tag on google cloud run using bitbucket pipeline.
Summary
To deploy a preview of your application to Google Cloud Run you will need to build a container image, push it to docker registry like GCR(Google Container Registry) and deploy to a cloud run by adding a tag to generate a preview URL for your change. You can use this preview URL to get your design and business QA inputs. Once this QA is done you are ready to send 100% traffic to this version.
Hopefully, this article gives some insight on how to preview your feature and ensure early collaboration. This approach at NEDigital has ensured that our changes are always pixel perfect and aligned with business requirements before merging into development or master branch.
Thank you for reading!
References
- https://cloud.google.com/
- https://cloud.google.com/run/docs/rollouts-rollbacks-traffic-migration
- https://bitbucket-pipelines.atlassian.io/validator
- https://support.atlassian.com/bitbucket-cloud/docs/configure-bitbucket-pipelinesyml/
