Working with Launch: Libraries

(For Feike, who was an awesome colleague, and a terrific human being)

(This may or may not be the first installment in a series of “Working with Launch” articles. I feel there are a lot of things that I want to write about, so we’ll see.)

Today, I want to point out two aspects of the “Library” concept that we work with in Launch:

1. why I think the way Libraries are done is cool and helpful, and
2. how to work with your live site and your dev Library.

Let’s dive right in!

Libraries and Changes

When you (or your friendly marketer, or an Analytics colleague) change things in Launch, you must test those changes before pushing them live.

This is where Launch is different, where it is not just an evolution compared to DTM.

Firstly, as someone who changes things in Launch, you should have your own Development Environment configured in Launch.

Having an Environment allows you to create and use a Development Library with precisely the changes you want to use or test.

Crucially, your Library does not have to contain Bob’s changes (or whatever that other person’s name is).

Secondly, switching from production to development in your browser is no longer just a question of adding “-staging” to the library name, as it was with DTM.

With Launch, every Environment has its own URL, meaning you have to explicitly point to your Development Environment when you want to load a Library you just built.

This will be part of your normal workflow, so I’ll show you three ways to do it.

But first:

Choosing what goes into a Library

It is up to you to decide what goes into a Library.

Or, more specifically, which changes go into a Library.

This is great, because it allows multiple people to work in Launch in parallel, while still keeping their changes separate (i.e. if I shoot myself in the foot in Launch, I won’t shoot yours, too, unless you let me).

The Library will always contain the current production code, too, sort of as a base for your changes.

How do you choose what goes into your Library?

When you first create or later edit the Library, the UI lets you “Add All Changed Resources” via a button at the bottom.

This is the easiest way, and if you are alone on Launch, it is perfect. If someone else is making changes, too, then you must be more picky, and here is how you can do that without losing your cool.

First of all, assign the Library you are creating to your dev environment.

See how the blue “Save” button turns into a “Save & Build for Development”?

Good. Click that button to create what is essentially an empty, boring Library.

The system will now build your Library. There’s nothing in there, but it can be built.

And now, we can prepare for making changes, and it is a pretty simple preparation:

Whenever you work on something, build a Library for it, then select that Library as your “Working Library” in the top right.

From now on, whenever you change something, the button at the top will be a “Save & Build for Development” button, meaning the change will a) be added to the Library, and b) that Library will be built.

Your development Library will always contain your changes, and it will always be built automatically when you make them.

Great time saver!

How to work with your Dev Library

Now that your stuff is part of a Library, how do you use that Library?

Personally, I am a big fan of working on the live web site with my dev Library. How do I do that?

There are currently three ways (two of them for Chrome, only):

1. the Adobe Experience Cloud Debugger,
2. the DTM and Launch Switch, and
3. Charles

All three of those can replace the Launch production Library, and inject your development Library instead.

The first and second are Chrome Extensions, meaning they will only work in Chrome.

For the first and third way, you will need the “embed code””or URL of your dev Environment.

Go to the “Environments” tab in Launch to find it:

Find your Environment, then click the icon on the right (in the “Install” column).

There is a little “copy” button next to the line you have to copy, click that. Then paste to somewhere, like an empty editor window. You’ll need this later.

Adobe Experience Cloud Debugger

The Adobe Experience Cloud Debugger (let’s call it AECD, shall we?!) is a Chrome Extension built to help with all of the Experience Cloud solutions, not just Launch. It has a lot of stuff on offer, which means it should probably have an article or two of its own.

For now, we are interested in the “Replace Launch Embed Code” feature, which lives under the “Tools” tab.

If you load a page containing Launch production code, and you paste the embed code for your dev Environment into this, the AECD will make the browser load your dev Library.

Easy.

DTM and Launch Switch

The DTM and Launch Switch is a Chrome Extension built by Search Discovery. Some of you might remember it from the good old, simple days of DTM staging libraries.

You install the Extension, then log into Launch, go to the Property you’re working on, head over to the “Environments” tab, then click the Extension icon.

As a result, DTM and Launch Switch saves the available Environments.

Now, if you head to the web site you’re working on, the Extension will see that Launch is loaded, it will see that it knows about the Property, and if you click the icon, it will allow you to switch Environments.

Super easy.

Charles

I love Charles, as you know. I have also written about the “Replace” feature, which is exactly what you would use here.

Since I have already written about it, I will stop at this point, and let you work with Launch.

Now that you know all about Libraries and how to use them, it should be great fun!