An alternative to Netlify deploy previews to validate early and faster

In this post, I'm going to describe to you the necessity of why we adopted this workflow to help stakeholders to validate new UI fixes and features faster.

Why?

As I mentioned above, the idea was to adopt a continuous delivery workflow to frontend team, when we implement every fix or feature on a specific branch, before the implementation, we open a pull request directly to master branch, so we can validate more early and faster than the conventional way, wherein the best-known way of workflows we use an implementation branch to staging as develop branch, and then to production, as master branch.

Based on the Netlify deploy previews, where we can deploy a specific branch content to a specific application URL, so, with some branch environments deployed, we can validate multiples branches, each one with its feature and then it goes straight to the master branch and production environment.

How?

As we decided to use another infrastructure and CI/CD tool instead of Netlify, we found a system that I think is working very well, actually using S3 buckets and CircleCI to our company design system called Momentum which you can visit the source here.

In our pipeline, during the last step, we deploy the application with conditions based on the branch name.

Before the branch was merged to the master, we have a Github webhook that calls lambda to delete the bucket with the branch content.

Now, I'm going to continue to explain more about the script above.

First of all, as we use feature/ch123, chore/ch123 or bugfix/ch123 (ch of Clubhouse to tracking), we should replace the / to - because of the URL.

BRANCH_NORMALIZED="${CIRCLE_BRANCH//\//-}"

Here, we do the conditions based on the branch name, when master we deploy to the production environment.

if [ "${CIRCLE_BRANCH}" == "master" ]; then
  echo "Sync bucket to production environment"
  sync_bucket s3://momentum.somar.io

Otherwise, that means we can have a feature, chore or bugfix branch when now, we should verify if this branch already did deploy because then we can just sync the content from the bucket, otherwise, we need to do the following steps, create the bucket, assign a public policy, active the redirect, and finally sync the bucket with the content.

else
  # This conditional check if this branch already has a bucket
  if aws s3 ls "s3://$BRANCH_NORMALIZED.momentum.somar.io" 2>&1 | grep -q 'NoSuchBucket'; then
    echo "Create the bucket"
    aws s3api create-bucket --bucket $BRANCH_NORMALIZED.momentum.somar.io --region us-east-1

    echo "Assign public policy access"
    aws s3api put-bucket-policy --bucket $BRANCH_NORMALIZED.momentum.somar.io --policy "{
      \"Version\": \"2012-10-17\",
      \"Statement\": [
        {
          \"Sid\": \"AllowPublicReadAccess\",
          \"Effect\": \"Allow\",
          \"Principal\": \"*\",
          \"Action\": \"s3:GetObject\",
          \"Resource\": \"arn:aws:s3:::$BRANCH_NORMALIZED.momentum.somar.io/*\"
        }
      ]
    }"

    echo "Active redirect to index"
    aws s3 website s3://$BRANCH_NORMALIZED.momentum.somar.io --index-document index.html --error-document index.html

    echo "Sync bucket"
    sync_bucket s3://$BRANCH_NORMALIZED.momentum.somar.io
  else
    # Here, we are only syncing the bucket with the new content
    echo "Sync bucket"
    sync_bucket s3://$BRANCH_NORMALIZED.momentum.somar.io
  fi
fi

Conclusions

And to finish, we'll create a lambda listening webhooks events from Github branches, when a branch was deleted, we take the branch name and find the bucket that contains the branch content and delete it.

It's something that has been working well and increasing a lot of value at our company and our flow, we can validate early with stakeholders, with a different way of having just a single validation environment, like staging.