Our Ember App (pre-engine)

billing-ui

• 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"
                        

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

• Deploys develop + our latest engine to https://apps.inindca.com/directory-billing/
• We will use this URL to run our automation tests

Step #3: Automation Job

• Our tests are pointed at https://apps.inindca.com/directory-billing/
• We browse to our engine after logging in https://apps.inindca.com/directory-billing/#/admin/billing/subscription
• Runs P1-P5 tests

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