(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:
- why I think the way Libraries are done is cool and helpful, and
- 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.
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):
- the Adobe Experience Cloud Debugger,
- the DTM and Launch Switch, and
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.
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.
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!
6 thoughts on “Working with Launch: Libraries”
Hi Jan, definitely think this would be a great series! What if two devs wanted to test different versions of the same rule? In a super simple example, Dev1 is implementing and testing eVar1 on a global page load rule, while Dev2 is implementing and testing eVar2 in the same rule. I can’t really work out what the workflow is, because they both need to add the same resource to their environments.
Correct, that is a limitation of the current model.
You could work around that by having dev1 and dev2 create a copy of the Rule and change their copy. Not great, but doable.
Nice one Jan,
I think one more nice feature, if there is a way to develop as a core library for all core changes and extend/inherit to all web properties , that way one shot change can be published with less time and less code.
Hi Jan, nice article – thanks!
A week ago I came across an issue with DEV libraries – a library was published and there is no current library left in DEV. I will got a 404 error when trying to load the DEV snippet for launch. Did you experience something like this, too?
As far as I can see, only way to get around this, is always creating a new “empty” DEV library immediately after publishing. Actually I didn’t notice the issue until web-devs came up to me with this. Would you provide the web-devs only the -staging and prod-snippets and use DEV only for Launch devs?
Yes, that is normal behaviour.
My way around it is to never embed the dev snippet anywhere, but to use the DTM and Launch Switch plugin, Adobe Experience Cloud Debugger, or Charles to replace.
Whether you would only ever use the production snippet, or the staging snippet in some cases, really depends on your workflow.
Does that help?
Yes, good to know! Would be nicer if DEV would still contain the latest PROD (or staging) code if there is no current DEV library with any changes, but at least now I know for sure. Thanks!