Launch libraries – Dev/Staging/Prod

When I am asked what Launch is, and I want to keep it abstract, I usually say that Launch is at the base a script manager. It allows people to use a UI, and it generates Javascript, which can then be added to your web site to do stuff.

Ok.

Terms

The process of generating Javascript files is called “Build” in Launch. Unlike DTM, Launch never builds unless you tell it to. DTM used to build a “staging library” whenever you saved any changes. That is not the case in Launch!

Out of the box, you would see three “Environments” in Launch:

1. Production,
2. Staging, and
3. at least one Development

There can be as many development Environments as you need. If you have three colleagues who tend to work in Launch, you should assign each their own dev Environment.

Why?

Because when you build, the Javascript code gets bundled and added to one of the Environments.

How does it get bundled?

Well, a Launch user can decide to create a “Library”, and they can add elements to that Library, usually changes they have just made.

If I log into Launch, change a Data Element and a Rule, my next step is to create a Library, attach it to my dev Environment, add the two changes, build and then test it.

Apart from the two changes I added to my Library, “everything that is currently in production” will also be in it.

What?

When Launch builds my Library, it uses the latest published Library as the base, then adds my changes.

This, btw, is why you cannot delete things in one go! There would be a risk of pulling elements from under the feet of others, hence the disable-publish-delete-publish flow.

You’d create and assign each of the three colleagues their own Environment, because that way, they can make changes mostly without stepping on each others’ toes.

Note that this is limited to them working on separate elements. If two of them change the same Rule, they will both have to add that same Rule to their Libraries, and probably also other elements that played a role in the changes.

If I create a Data Element “Page Language” and add it to the “All Pages | None | DOM Ready | [AA,AT]” Rule, and you create a Data Element “Page Template” and add it to the same Rule, we will both have to add all three changes into our Libraries.

Fallbacks

When you first create a Launch Property, it is best practice to immediately create a Library, add something (maybe just the Core Extension) to it, build, approve, publish.

That way, when you embed any Environment into any site (we get to that), there will be code available and you won’t see a 404 error.

When you have created and published your first Library, you can safely embed all Environments into any sites. Yes, including staging and all dev Environments.

When Launch is instructed to load any Environment, it will use fallbacks as necessary.

• Tell it to load the prod Environment, and it’ll do just that, or fail with a 404 if no Library has ever been published.
• Tell it to load the staging Environment, and it’ll do just that, or load the prod Environment if there is currently no Library in the staging Environment.
• Tell it to load a dev Environment, and it’ll do that, or fall back to staging, then prod, if necessary.

Makes sense?

Quiz. In the screenshot here, which Libraries are loaded?

1. On a page that embeds the Production Environment, which Library is loaded?
2. On a page that embeds the Staging Environment, which Library is loaded?
3. On a page that embeds the “Dev2” Environment, which Library is loaded?

What do you think?

The answers are: “test”, “test”, and “Blog test 2”

What about “Blog test 1?” you ask?

Well, look at the little dots, or the Environment.

Libraries don’t have to be attached to any Environment!

If you see a green dot, or if there is an Environment listed, then the Library is available. If the dot is orange, and the Environment says “None”, then it isn’t.

In real life, the Staging Environment will only very rarely contain a Library.

That Library usually gets there when someone wants to explicitly test the Library, and they therefore use the “Build for Staging” menu item.

You can then immediately see the display change, even while the Library is building.

And once it is done, you’ll see the green dot.

Publishing follows the same pattern. Once the Library is approved, it is not attached to any Environment, until someone uses the “Build & Publish to Production” menu item.

And now you know why the fallbacks exist and are important!

And you can also guess that when you work on something but need to focus on something else for a moment, you can do something similar to a stash, simply by detaching your current dev Library from your dev Environment, creating a new one, working on that until done, then re-attach your old Library back.

Comfort

DTM used to simply build the staging environment whenever you saved any changes.

Since that is very convenient, you can also do something similar in Launch.

The concept is called a “Working Library”, and you can find it at the top right of the Launch UI.

When you designate a Library your Working Library, all “Save” buttons in Launch will instead become “Save to Library and Build” buttons or “Save to Library” buttons.

That means that Launch will build your Library whenever you save a change, and you don’t have to manually trigger it.

There is also a nice, new “Build” button next to your Working Library on every screen in the Launch UI, for even more convenience.

AEM

With DTM, I once told you to always embed the production code.

DTM’s trigger-happiness for dev Library builds was the reason for that. In my opinion, no site, dev, UAT, staging, whatever it would be called, should ever, by default, embed potentially broken code.

With Launch, that is now solved!

You embed the production Environment on your production web site, and the staging Environment everywhere else.

If any of your developers want to embed a dev Environment, then I would seriously wonder whether they would actually be both, a Launch user and AEM dev. Otherwise it would make no sense for them to embed dev.

The good thing about embedding a staging Environment: most of the time, it’ll be the production code. And when someone wants to approve, they can do so simply by building the Library in Launch for the staging Environment.

By the way: Launch is smart enough to handle the fallback in a way that makes sense.

Example: in the Analytics Extension, you can assign different Report Suites for dev, staging, and production Environments. That way, data from test or staging systems doesn’t “pollute” your production data.

This works in cases of fallback. When you tell Launch to load the staging Environment, it’ll pretend to do so even if it falls back to production. From the point of view of Analytics, it’ll be the staging Environment.

Cool, hm?

And much easier then with DTM, I think!

Author v Publisher

With AEM, every site you build exists twice: you have a publisher, which hosts the site as visitors see it. And you have an author, on which your colleagues create and edit content.

The past and current integrations between AEM and DTM/Launch have treated author like publisher, meaning you were able to deploy the Launch production Environment on author.

In my (humble?) opinion, it would make more sense to deploy a different Launch Property on author. While I want to be able to analyse visitor behaviour on the live site (on publisher), on author I would probably want to know how the content authors edit and create, and so the setup would be very different.

Right now, with the integration as it is, I would probably not deploy on author at all.

Conclusion

If you look at the big picture, this is what you should see:

• 3 environments in AEM: production, staging/UAT, dev
• 1 publisher per environment, plus 1 author, so 3 publishers & 3 authors
• 1 Launch Property
• 3 or more Launch Environments: productions, staging, 1 or more dev
• Launch production Environment embedded on AEM production publisher
• Launch staging Environment embedded on AEM staging/UAT and dev publishers
• No Launch embedded on the 3 authors
• 2 Report Suites in Analytics, 1 production, 1 dev
• Analytics Extension in Launch configured to send data to production Report Suite in production Environment
• Analytics Extension configured to send data to dev Report Suite in dev and staging Environments

And that’s it. Easy!