Development Workflow

After the build process was executed and the artifacts we want to deploy have been created, our Redirector Service permits us to deploy the artifacts to either assets.emarsys.com (Staging) or assets.emarsys.net (Production) in so called "S3 Buckets". A "S3 Bucket" (S3 means "Simple Storage Service") is similar to a file folder, and hosted via the AWS public cloud storage.

The files/artifacts stored in the "S3 Bucket" can be fetched through:

For a complete list of the files/artifacts (the file names) refer to this chapter.

Automated build and deploy

Build Artifacts

Our build process creates the following artifacts and places them into a local folder called public:

  • web-emarsys-sdk.js: The web packed web push SDK code.

  • web-emarsys-service-worker.js: A web packed service worker code which has to be used in browsers which support VAPID.

  • service-worker.js: A small code file which contains the import statement of web-emarsys-service-worker.js. The file can

    • either be downloaded by customers and placed in the root folder of their own website. So customers do not have to write that code by themselves and are prevented to make a mistake when inserting the URL which point to the web-emarsys-service-worker.js file or

    • they can provide the file indirectly by just referencing and serving it through a proxy (which makes it look as if the file is coming from their own website). This option (using a proxy) is necessary for the usage of the service worker in Shopify.

Deploy to Staging

  1. Branch from master for a new feature.

  2. Commit using the Conventional Commit Standard when writing the commit comment

  3. Create a pull request, get it reviewed and approved, then merge to master.

  4. A Github Action main.yaml is triggered.

    • Tests are executed.

    • Artifacts are built.

    • All artifacts contained in the projects public folder are deployed to the staging assets.emarsys.com using the Redirector Service.

      • For staging deployments before 2022-02-23, the UNIX timestamp in seconds (when the deployment happened) is used for the VERSION. For deployments after 2022-02-23 the first 10 characters of the Git commit SHA are used as the VERSION. So the pull request for a specific staging version can be found easily.

    • Finally a release pull request is automatically generated by using the Google Release Please Action. The action updates the version number in the projects package.json file. For an example of such a generated release pull request have a look at this pull request.

Deploy to Production

Just merge back the release pull request and a new github release is going to be created. That triggers the Github Action release-production.yaml which will create the "S3 Bucket" using the version from package.json and copies all artifacts which are contained in the public folder to this bucket.

Debug a deployment

Check the S3 bucket using aws cli

[assets-uploader]
aws_access_key_id = <AWS_ACCESS_KEY_ID>
aws_secret_access_key = <AWS_SECRET_ACCESS_KEY>

  • Check all the deployments

$ export export AWS_PROFILE=assets-uploader
$  aws s3 ls ems-assets[-staging]/web-emarsys-sdk/

How can I find the most actual version?

The link to the most actual version on staging or production can be found via the Redirector Service

  • For Staging use

$ curl --head https://redirector-staging.eservice.emarsys.com/web-emarsys-sdk/latest/

  • For Production use

curl --head https://client-version.cf.emarsys.net/web-emarsys-sdk/latest/

Curl will display the header information of the received response. In this header, just look for the location entry and you have the full path to the latest staging/production version.