Historical context
Mixmax's Chrome extension historically operated as a dual-component system: a "core" shell and a "source" frontend. Under Manifest V2, this architecture allowed for seamless updates by loading dynamic JavaScript, minimizing the need for Chrome Web Store releases. However, the introduction of Manifest V3 necessitated a complete overhaul of our release process given the increased dependency on Google's approval system.
Understanding Our Starting Point
Before redesigning our pipeline, we conducted a thorough analysis of our existing process, which revealed several challenges:
Existing Pain Points
- Complex Branch Management: We had 4 different branches (master, override-staging, beta, and production) that often led to frequent merge conflicts
- Fragile Deployment Process: The upload/deploy process was tightly coupled with the build process, making retries difficult
- Version Control Issues: Semantic-release sometimes failed to increase version numbers correctly and the beta/production builds had different version numbers
- Google's Approval Process: No visibility of whether the deployment is approved
- Roll-out Complications: Developers without access to the Webstore couldn’t manage partial roll-outs
Core Requirements
After analyzing our situation, we established clear constraints across three key areas:
Testing Needs
- Ability to test without Chrome Store involvement
- Maintain a reference build for automated QA testing
Release Management
- Version numbers must always increment and remain consistent between channels (public or beta)
- Cannot upload new versions until previous ones are approved
- Need flexibility in managing roll-out percentages
- Must support static asset releases to different environments (more on this later)
Environment Support
- Must work across local, staging, QA, and production environments
- Support for both beta and production release channels
The Reimagined Pipeline
Our solution addressed these challenges through three main components:
Single Branch Strategy
- Single master branch instead of four
- Preview builds generated directly from pull request branches
Automated Workflows
- Separate workflows for beta and production releases
- Automatic release of static assets with QA assertion
- Manual triggers to ensure control over the release (gate)
- Built-in support for partial roll-outs
Weekly Release Cycle (manual)
- Monday: Beta to production (10% roll-out) + New master to beta
- Tuesday: Increase to 30% if there are no issues
- Wednesday: Increase to 100% if stable
Here is a visual summary of how that translates to actual continuous integration steps (after merging a code):
Technical Implementation Details
The Two-Step Release Process
If you look closely at the image above, you might be asking yourself why it is required to build, deploy, and run smoke tests on the extension for different environments, and why would the deployment phase happen before the “gate” steps. That is a good question! Here is why:
The extension is actually released in 2 steps:
- A release of static assets
- A release of the Chrome extension in the webstore
What does it mean to “release static assets” and why it is needed?
Our Chrome extension modifies 3rd-party websites. It does so by grabbing specific selectors and mutating the DOM of those websites. Because we don’t control those 3rd-party websites, unexpected changes can break our extension. To be able to quickly react to those changes, we separate the critical bits and deploy them separately: CSS and page selectors are statically deployed and that happens as fast as possible!
So, to recap the image above, as soon as the new code lands on master, it builds & releases the static assets to staging. And then, it runs smoke tests against it. This type of change (a static asset) is backward compatible: The newer version of the static assets will run with the old version of the Chrome extension until that newer version reaches the user.
GitHub actions
The real magic sauce is how we combined Github actions with this new process.
In summary, those are the CI files that compose the process:
-
ci.yml— the main one# ci.yml
name: continuous-integration
'on':
push:
branches:
- master
jobs:
# Release via semantic-release
release:
if: github.event.head_commit.author.username != 'semantic-release-bot'
uses: ./.github/workflows/semantic-release.yml
secrets: inherit
# Build & deploy static assets + QA (Staging)
build-and-deploy-staging:
needs: build-and-deploy-qa
uses: ./.github/workflows/build-and-deploy.yml
secrets: inherit
ext_stg_smoke_tests:
needs: build-and-deploy-staging
uses: ./.github/workflows/extension_stg_smoke.yml
secrets: inherit
with:
extension_public_url: $
# Build & deploy static assets + QA (Production)
build-and-deploy-prod:
needs: ext_stg_smoke_tests
uses: ./.github/workflows/build-and-deploy.yml
secrets: inherit
with:
override-environment: production
ext_prod_smoke_tests:
needs: build-and-deploy-prod
uses: ./.github/workflows/extension_prod_smoke.yml
secrets: inherit
with:
branches_for_test_execution: |
["master"]
extension_public_url: $
# For BETA build and publish
build-and-deploy-beta:
needs: ext_prod_smoke_tests
uses: ./.github/workflows/build-and-deploy.yml
secrets: inherit
with:
override-environment: beta
publish-to-beta:
needs: build-and-deploy-beta
uses: ./.github/workflows/publish-or-update-rollout.yml
secrets: inherit
with:
target: beta
deployPercentage: 100
# For PUBLIC, publish with 1% deploy percentage
publish-to-public:
needs: publish-to-beta
uses: ./.github/workflows/publish-or-update-rollout.yml
secrets: inherit
with:
target: public
deployPercentage: 1 -
build-and-deploy.yml— builds the extension and deploy to s3 (static assets and the extension zip)# build-and-deploy.yaml
# This is a simplified version
name: Build and Deploy
on:
workflow_call:
inputs:
override-environment:
required: false
type: string
outputs:
extension-url:
description: 'S3 url of the built artifact'
value: $
env:
TARGET_ENVIRONMENT: $preview
permissions:
# Reduced set of necessary permissions
contents: write
id-token: write
jobs:
build-and-deploy:
runs-on: ubuntu-latest
outputs:
extension-url: $0
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v4
with:
node-version-file: .nvmrc
cache: npm
# To allow S3 uploads
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-region: us-east-1
role-to-assume: $
# At this stage, semantic already ran so we can grab the version from package.json
- name: Set Environment Variables
run: |
echo "VERSION=$(cat package.json | jq -r '.version')" >> "$GITHUB_ENV"
echo "GIT_SHA=${GITHUB_SHA}" >> "$GITHUB_ENV"
- name: Build Application
run: npm run build:$
# Upload to Github actions
- uses: actions/upload-artifact@v4
if: $false
with:
name: extension-artifact-$
path: $
retention-days: 10
overwrite: true
- name: Upload to S3
id: upload-artifact
run: |
BUCKET=mixmax-extension-$
BUNDLE_NAME=$(echo *.zip)
aws s3 cp $BUNDLE_NAME "s3://$BUCKET/versions/$VERSION/$BUNDLE_NAME/" --cache-control 'max-age=0, must-revalidate' --acl public-read
aws s3 cp $BUNDLE_NAME "s3://$BUCKET/versions/latest.zip" --cache-control 'max-age=0, must-revalidate' --acl public-read
BUNDLE_URL=https://$.s3.amazonaws.com/versions/$VERSION/$BUNDLE_NAME
echo "EXTENSION_URL=$ARTIFACT_URL" >> "$GITHUB_OUTPUT"
# Prepare and upload HTML, CSS, assets with appropriate headers
- name: Upload Static Assets
run: |
BUCKET=mixmax-extension-$
aws s3 cp static_dist/ "s3://$BUCKET/static/" --recursive --cache-control 'max-age=0' --acl public-read -
publish-or-update-rollout.yml— changes the extension in the Chrome Webstore# publish-or-update-rollout.yml
name: Publish Chrome Extension
on:
workflow_call:
inputs:
target:
required: true
type: string
deployPercentage:
required: true
type: number
workflow_dispatch:
inputs:
deployPercentage:
required: true
type: number
version:
description: 'Version to deploy (must match git tag) - ex v1.2.3'
required: true
type: string
permissions:
# ... relevant permissions ...
jobs:
publish:
runs-on: ubuntu-latest
env:
CHROME_CLIENT_ID: $
CHROME_CLIENT_SECRET: $
CHROME_REFRESH_TOKEN: $
BETA_CHANNEL_ID: your-beta-extension-id
PUBLIC_CHANNEL_ID: your-public-extension-id
TARGET: $
environment: $
steps:
- name: Validate version
if: $false
run: |
if [[ ! $ =~ ^v[0-9]+\\.[0-9]+\\.[0-9]+$ ]]; then
echo "Invalid version format"
exit 1
fi
- uses: actions/checkout@v2
with:
ref: $
- uses: actions/setup-node@v4
with:
node-version-file: .nvmrc
cache: npm
- name: Download extension artifact
if: $false
uses: actions/download-artifact@v4
with:
name: extension-artifact-$
- name: Publish extension
run: |
COMMAND="npx chrome-webstore-upload-cli"
if [[ "$" == 'push' ]]; then
COMMAND+=" --source=path/to/extension.zip"
else
COMMAND+=" publish"
fi
# Add authentication parameters
COMMAND+=" --client-id=$"
COMMAND+=" --client-secret=$"
COMMAND+=" --refresh-token=$"
# Set extension ID based on target
COMMAND+=" --extension-id=$"
# Add deployment options
if [[ "$" == 'public' ]]; then
COMMAND+=" --deploy-percentage=$"
else
COMMAND+=" --trusted-testers=true"
fi
eval $COMMAND
Wait, but there is more
It is paramount that we test the extension before releasing it. We made that happen through a comment in the Pull request:
-
And for that, we have done a “preview” build and deployment:
# PIPELINE FOR PREVIEW BUILDS
name: continuous-integration
'on':
pull_request:
branches:
- master
jobs:
build-and-deploy-preview:
needs: checks
uses: ./.github/workflows/build-and-deploy.yml
secrets: inherit
preview_pr_comment:
needs: build-and-deploy-preview
runs-on: ubuntu-22.04-8-cores
steps:
- name: Find existing comment
uses: peter-evans/find-comment@v3
id: fc
with:
issue-number: $
comment-author: 'github-actions[bot]'
body-includes: '<!-- preview-deploy-comment -->'
- name: Comment link to extension build in PR
if: $true
uses: actions/github-script@v7
with:
github-token: $
script: |
const url = '$';
const message = `<!-- preview-deploy-comment -->
> [!NOTE]
> Subsequent updates in this Pull Request will be uploaded under the same URL below.
[Download extension build](${url}) for this Pull Request.`;
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: message
})
Managing the gate
After the automation runs, we can approve the pipeline for the different deployments:
And following our weekly cadence, devs with access to Github can create a new workflow to update the rollout percentage:
Shameless plug
After this whole saga, one feature is still missing:
Google's Approval Process: No visibility of whether the deployment is approved
And for that, we used the easiest tool: Mixmax! You can try it out for free. Here is how:
- Set up your Mixmax account at https://app.mixmax.com
- Go to the Rules page and create a rule as such:
- Trigger = “I receive an email”
- Filter = “From(email) is chromewebstore-noreply@google.com”
- Action = Slack > “Send channel message”
Conclusion
Our new pipeline has significantly improved the Chrome extension release process, reducing labor and increasing reliability. With GitHub Actions, AWS S3, and Chrome Web Store APIs, we've created a powerful and maintainable process. And, on top of that, Mixmax helps us track Google's approval process, addressing all previous pain points.
A good release pipeline balances control, speed, and reliability. We believe this solution achieves that balance effectively.
I hope you have learned at least one or two deployment best practices and/or caveats for your Chrome Extension deployment!
Happy deploying! 🚀
Interested in joining the team? Visit Mixmax Careers.
