First things first: I will move to a monthly release cycle.
The last year or so has been a total write-off for all of us. I am feeling it, sometimes more, sometimes less, but I am. I have seen what happens when you simply keep going, and it’s not nice, so I am cutting back.
From now on, there will be a post on the first Tuesday of the month, unless I happen to have one of my moments of crazyness and produce some mini-series.
Given that the number of posts per year seems to be a major driver behind popularity, this hurts, of course. I am also feeling that I am letting you and myself down. My apologies.
With that out of the way, let me show you the results of a little experiment.
Libraries and the “Upstream” concept
In Launch libraries – Dev/Staging/Prod, I wrote:
When Launch builds my Library, it uses the latest published Library as the base, then adds my changes.
and
When Launch is instructed to load any Environment, it will use fallbacks as necessary.
The former ensures that whatever people change will be based on some sort of stable foundation, and the latter means that as long as there is something published, all Environments will work.
From my point of view as a not-that-great Javascript mangler, that gives me a lot of confidence.
And it leaves room for interesting thought experiments, such as this one:
Say there is some element in production. Now developer #1 comes, changes that element, puts into a Library on her Environment “dev 1” and builds.
I guess we all agree that in production, the element will stay as it was, and that only developer #1 will see her changed element at this point.
Developer #1 has a conference call, and so she exits her browser.
At this point in the story, developer #2 opens their browser and logs into Launch. They find their way into the same Property, and they change the same element. They add it to their Environment “dev 2” and build.
Question: what will developer #1 see when she comes back?
I do not know!
What do I do when I don’t know? Well, I try it!
Setup
I built 3 pages, each loading the respective Environments:
- Page 1 loading the ‘production’ Environment,
- Page 2 loading the ‘dev 1’ Environment, and
- Page 3 loading the ‘dev 2’ Environment.
The code on these pages is simple, and it is the same for all three of them. Feel free to check. Here is the code for page 1, as an example.
<html>
<head>
<title>Testing Libraries and Upstream</title>
<style>
span {
font-weight: bold;
}
</style>
<script src="//assets.adobedtm.com/3028746f70eb/015987a231e1/launch-0c60deece2f7.min.js" async></script>
</head>
<body>
<p>Testing the "upstream" concept with Launch.</p>
<p>This page loads the 'production' Library.</p>
<p>The value of the Data Element is <span id="devalue">TBD</span>.</p>
<hr />
<p>There are two more pages for the <a href="libtest2dev1.html">'dev 1'</a> and the <a href="libtest3dev2.html">'dev 2'</a> Environments.</p>
<p>All Environments are configured as described in the blog article <a href=""></a></p>
<script>
setTimeout(function() {
// read the value from the Data Element
var element = _satellite.getVar('Element');
// find the space in the page where it should be
var span = document.querySelector('#devalue');
// put it there
span.innerText = element;
}, 5000);
</script>
</body>
</html>
There is a script tag towards the bottom. Five seconds after the page loaded, it reads the value of a Data Element, then displays that on the page.
So, you guessed it, I am using a Data Element for this test. Thanks to some guy’s contribution to the Core Extension, I can use the extremely simple “Constant” Data Element Type.
This is the configuration that I pushed through into production:
Side Quest – a Surprise
A note, because I was surprised: when I first built the Data Element, I did it using the “dev 1” Environment. I did not immediately push it all the way through, instead I built it in “staging” (aka Submitted), like so:
I then accidentally re-loaded the page that embeds the “dev 2” Environment, and lo and behold, there was a 404 and no _satellite object!
Hmm…
When I created an empty Library for the “dev 2” Environment, the 404 went away, of course.
My thought at this point was “well, I have never had this happen for a pre-defined development Environment”, but then I realised that I’m an idiot, because — d’uh! — the only way to get something to production is via a dev Environment, so it could never happen.
Ok. So what if I delete that Library now? Wanna guess?
Yup: fallback works as expected.
My working theory, in the absence of a way of looking into Ben Robinson’s mind, is that the “upstream connection” is established when the first Library is built for a new Environment. In other words: fallback will work for Environments that had at least one build.
Back to the regular program.
The Test!
Developer #1 was early that day, and she started by making a change to the Data Element. She created a Library on her “Dev 1” Environment, built it, tested, and was happy.
Next, developer #1 went to her call, and developer #2 arrived on the scene.
They changed the Data Element, created a Library for their “Dev 2” Environment, then built.
Uh… this is exciting! (picture Christoph Waltz as Hans Landa: “That’s a bingo!”)
First, I look at page 1 (the “production” Environment):
No surprise here. Next, page 3 (the “Dev 2” Environment):
Equally unsurprising.
And on this cliffhanger, I’ll leave you. Next month, we’ll learn what exactly developer #1 saw when her conference call finished and she opened that page again.
Bad joke? Bad joke.
Believe it or not, I am typing these lines and I have not yet checked.
My thinking is this: developer #1’s “dev 1” Environment is currently holding what she compiled earlier. The green dot is still there, and it’s still green.
So I think she should still see the value that she put into the Data Element.
Check… yes, she does:
What if she builds her Library, without changing anything else?
My guess: she’ll see the new value, right?
Nope, she won’t!
When developer #2 changed the value of the Data Element, they created a new “revision”, and they added that revision to their Library. Developer #1, though, still has her revision in her Library. So when she builds, she gets her value.
Makes sense, I think.
Notes
I think the concept is simple, and safe, and I like that.
There seems to be one exception. There usually is.
When you update an Extension, it also shows as a new revision. The difference in this case is that noone can build a Library that contains anything but the latest revision of the Extension!
If two Libraries in two development Environments contain the Extension, and one is built with a later revision, the other can no longer be built, unless the latest revision of the Extension is selected here, too.
(Do I build an Extension just to test this? Of course I do…)
(Half an hour later)
Confirmed.
We can build Libraries that contain “outdated” revisions of Data Elements or Rules, but noth of Extensions.
I guess it makes sense.
Extensions deliver code straight into the Library, which can potentially affect every other part of code in it. It makes sense to force this.
Or: no Library should ever be submitted for approval that hasn’t been built with the latest versions of all the Extensions.
I can live with that.
Web Analytics for Developers 
The basic idea about understanding what is going on here works like this I guess. Anytime you build a library into any environment what happens is that the code (all the reactor stuff, extensions, rules/conditions/actions and de) gets concatenated and compiled and puked out to the specified destination (assets.adobedtm.com/***). In other words it just creates static files on some location that may be referenced from the page (what you descibe only corresponds to “Managed by Adobe” hosting option with “Create archive” toggle off).
When you create a new Environment, no code was published yet and there are no files on the respective destination > 404 (and I gues that this should also apply to the default environments in a brand new property).
And the versioning is pretty simple here – you also cannot “rollback to previous versions” like the developers might expect – you can only use a historical version and copy it into a fresh “Latest” version of itself.
LikeLike
Hi Lukáš,
I think that sounds like a useful mental model, yes.
Cheers,
Jan
LikeLike
Nice shaare
LikeLiked by 1 person