Build & Deployment Pipelines for Ember Engines

Tony Ward

Our Ember App (pre-engine)


  • billing-ui repo
  • billing-ui was iFramed into Admin UI
  • Our pages were accessible by logging into directory > Admin > Account Settings > Subscription

Since we were iframed in...

  • web-directory would deploy whenever
  • AdminUI would deploy whenever
  • We would deploy whenever

As long as no regressions in iframing us in, everything was 👍

Pre-Engine Pipeline

Build Job

  • Ran unit and integration tests
  • Built it, deployed out to dev environment

{env} Automation Jobs + Promotion Jobs

If automation tests pass, promote up, expanding automation test coverage

Promoted to Stage, All Tests Passed

Put up a CM request and ship it to prod

Sweet Pipeline!

This pipeline was nice, because it ensured tests gated promotion to higher environments

But wait! Now we are an engine...

                            // package.json
                            "ember-engine-billing": "^2.0.0"
  • We are a dependency inside of web-directory
  • Whenever they push to an environment, we do too
  • We can't use the existing pipeline anymore

Today's Topic

How can we ensure the version we push out with web-directory has hopped through all of the testing hoops and is prod ready?

A few quick notes...

We have an existing, working pipeline where we pin the version of our engine in web-directory

We have a suggestion if you're using semantic versioning in your engine, but the pipeline isn't built yet

Quick Overview of Both Pipelines

  • Run lots of dev tests (unit, integration, and acceptance tests on our engine and web-directory)
  • Take web-directory's develop branch, tell it to use our latest engine code, and deploy it out to a custom DCA URL
  • Run a bunch of automation tests against our latest engine
  • Let those tests gate either the artifactory push (semver) or a manual PR to web-directory (pinned)
  • Kick off additional automation tests when web-directory deploys to other environments

Pre-req: Setup your engine DCA URL

  • Add Your Ember Engine Custom URL to Directory's OAuth Config
  • This is where web-directory + your latest engine will be deployed
  • Only have to do this once

Building and Deploying Ember Engines (pinned)

ember-engine-billing view in Jenkins

Pin the Engine

We pin our version in web-directory's package.json

                        // package.json
                        "ember-engine-billing": "2.0.0"
  • This pinned version should be considered "production ready"
  • It passed all automation tests
  • We know the exact version that will get deployed

Step #1: Publish Job

  • Typical job everyone else uses, but is wired to fire off when something merges into master
  • Runs our unit, integration, and acceptance (soon ™) tests
  • Auto-increments the patch version (respects major/minor bumps)
  • Pushes to artifactory

Step #2a: Build Job

  • Pulls the latest web-directory develop branch
  • Utilizes npm to install the latest version of our engine from artifactory
                                              npm install ember-engine-billing@latest --save-dev
  • Runs web-directory's tests

Step #2b: Build Job

Step #3: Automation Job

Step #4: Manual PR

  • All tests passed? Great - put up a PR to web-directory to pin this new version
  • Your latest engine will now be deployed

Step #5: Additional Automation Tests

  • When web-directory deploys to any environment, kick off a non-blocking automation job
  • We prefer running smoke tests at this point

Building and Deploying Ember Engines (semver)

Semver Engine

web-directory pulls in your engine using semver via the package.json

                        // package.json
                        "ember-engine-billing": "^2.0.0"

Due to that, we should be careful when publishing new versions of our engine to artifactory

Pinned vs Semantic Versioning Pipeline

  • Shifting automation tests left, shifting publish to artifactory right
  • Automation tests now gate the publish to artifactory instead of gating a manual PR to web-directory

Step #1: Deployment Job

  • Pull down your latest engine from bitbucket
    • Run all unit, integration, and acceptance tests
  • Pull down your web-directory's develop branch
    • Run all unit, integration, and acceptance tests
  • Use npm to link your engine to web-directory and deploy it out to DCA (/directory-billing/)

Shared Steps

  • Step #2: Automation Job similar to pinned steps
  • Step #3: Artifactory Publish Job

Step #4: Profit (deploy)

  • Due to semver, web-directory will pick up your latest changes on the next deploy

Step #5: Additional Automation Tests

  • Same as pinned step

Advantages of these Pipelines

  • Automatic pushing to artifactory
  • The version of your engine in web-directory has the automation stamp of approval (on top of all dev tests!)
  • Can still kick off automation jobs at every deployment level

Next Steps

  • If other teams want to adopt this, should make nice Jenkins templates for reusability
  • Open to feedback
  • Create a semver pipeline
That's all folks'
Any questions?