Build and publish a tag library

Transcript

In this video, we’ll go over the process of how to build and publish a library and tags. We’ll cover some important concepts related to the publishing flow itself and walk you through the process of how multiple teams can move their libraries through the different stages of that flow. When you make changes to resources and tags, be there extensions, data, elements or rules, those resource changes must be added to a library before they can be published to your digital property for testing and deployment. In a typical workflow, a developer will create a new library in tags, and once they’re done adding their changes to the library, they’ll build it to a development environment for initial testing. Once testing is finished, the library is submitted to a staging environment where key stakeholders can review it. These reviewers can reject the bill back to the development stage or further work as needed, or they can approve the build and move it to the approved phase where it’ll be queued to move on to the final publishing stage where the changes are deployed to production. Before we dive in, let’s quickly recap what a library is in the context of tags. A library is a collection of capabilities that you’ve configured within the tags interface that’s compiled into a package of deployable client side code. When users interact with your property and tag will fire based on your configured extension’s data elements and rules. It’s the library code that makes this happen. Okay, let’s head into the tags interface and see how this works. I’m in a web property here, but the publishing process works the same way for all property types. Select publishing flow on the left now, and here are the four columns that correspond to the different stages and the workflow we covered earlier. Development submitted, approved and published. Any existing libraries on this property will appear in this view, and in this case I just had the one library under published here, which represents our initial build. We’ll be making a couple new libraries shortly. But before we start, let’s quickly go over what kinds of resources we’re working with in this property under environments. In addition to the standard development, staging and production environments, they come preinstalled. I have two other development environments for Lumos, two dev teams, Dev Team Alpha and Deputy Bravo. Remember that you can have as many development environments as you like so your dev teams can independently work on different updates at the same time without needing to worry about conflicts. In our case, both teams of are making changes to this property and we have a bunch of rules that we want to publish as well as a few data elements that are leveraged by those rules. So let’s walk through how these teams would divide their respective features between different libraries and publish their changes separately rather than all at once. We’ll head back to the publishing Flow tab, then select Add library. We’ll call this one Dev Team Alpha so we know which group this library’s for and we’ll assign it to the corresponding development environment for that team as well. And now we need to add some resources to this library, click Add new resource and we’re given a dialog that will let us choose the rules, data elements and extensions from our property that we want to include. I’ll go to rules first since Team Alpha is adding this global variables rule on select it, and I’m asked to pick a revision whenever you publish a resource, the initial version of that resource and any updates made to that resource in future libraries are each assigned a revision number. This allows developers to track changes to each resource as they update over time and resolve conflicts where multiple libraries make different changes to the same resource. Since this is a net new rule that hasn’t been published yet, we just have way this is the only option to choose from. So we’ll go with that and then click, select and create new revision. And there’s a rule added. We’ve got a couple more rules to add here as well, so we’ll quickly speed through these.

And once that’s done, we’ll remember these rules rely on some data elements that will also need to include. So we’ll add those as well. Note for this product info data element, we can see that we have another version available from our initial library build revision one, which is different from the latest version. Hovering over these options, we can see at a glance which one is live, and production, among other details, will choose the latest revision. And we’re given the option to compare this version with other revisions side by side. If we want to see more details. And from here we can see what’s changed between these two with the latest version of the data element having its path attributes slightly altered. This is the change we want to publish. So we’ll exit this view and add the latest version to our library. All right, this is looking good. So let’s click Save and built a development to compile our library code.

Well, looks like we forgot something. Whenever you try building a library, the system will check for any missing dependencies. And in this case, we forgot to include the web SDK extension. We can go back and make the adjustments manually if we want, or we can just click apply updates and continue to automatically add the missing resources and immediately move forward with the build. Once our library finishes building with a great success indicator, we can continue editing and rebuilding that library in the development column as needed. When we’re happy with our changes, we can submit it for review, select the options icon for the library, and we can choose to submit for approval if we want to just move this library over to the next column without building it to another environment yet. But in our case, we want our reviewer to test our build right away. So we’ll choose, submit and build the staging instead. Will confirm our choice and the library starts building in the next column. Notice the environment has changed to staging as well. The library can no longer be changed at this point unless we put it back into the development column. But while it’s under submitted, a reviewer can still click into the library itself and review its details as part of the assessment. Okay, so this library is under review and it’s going to take a minute for our reviewer to get around to looking at it. So while we wait, let’s step into the shoes of the other development team and make another library for what they’re working on. Just like before. We’ll click Add Library and we’ll call this one dev team Bravo pick in the corresponding environment as well. Now we could select add a resource to add our changes manually like we did before, but let’s say these two dev teams are the only ones working on this property. So we know that any change resources that weren’t included in Team Alpha’s library can only have been set up by Team Bravo. In this case, we can select add all changed resources instead. This option adds any resources found on the property that have been updated or added when compared to the resources upstream to define what we mean by upstream resources, let’s quickly refer back to the publishing flow when working with a library. Upstream refers to any resources contained in other libraries that are ahead in the publishing flow. In other words, what counts as upstream is relative to the library in question for libraries in the development column, upstream refers to anything under submitted, approved and published where a submitted or approved libraries will only consider publish as being upstream for any library. We can view these resources by expanding the resources upstream section. Why is this important? Well, whenever you attempt to build a library to an environment, the system won’t just test the change resources within that build. Rather, it includes all other upstream resources in that evaluation, as well as if they were natively part of the build. This is to ensure that no matter what changes, your teams attempt to publish in their development cycles, the system always tests whether those changes are compatible with all other resources that are further along the path to production. If not, live already. If any incompatibilities are found, the build will fail and it won’t be able to proceed. All right, let’s even build this. Depending on the changes you’re making to a library and how many other teams are simultaneously working on the same property. It may be daunting to select all these resource changes after the fact. Like we’ve been showing so far, This is where the working library feature comes in handy for any library that’s in the development column. You can use this dropdown to select it as you’re working library. When you do this, any changes you made to rules, data elements and extensions can be added to your library automatically. So for example, let’s pick Team Bravo as our working library and then we’ll create a new data element. It doesn’t really matter what type for this demo, so we’ll just choose random number under the core extension. Note though, that the save button now says Save the library instead. Since we have a working library selected clicking the arrow icon, we have some other options as well. We can still use the normal save option if we just want to add this change to the property without assigning it to our working library. But if we do want to add it, we also have the option to rebuild the library right away after we save the update. When making multiple changes to your working library, it’s often best to just saved a library rather than rebuilding after every change. When we choose this option, the status of our working library updates to Amber indicating a change has been made since the last successful build and it needs to be built again before it can continue to the publishing flow. When we are ready to continue, we can simply select build right next to the working library control and run that process from anywhere in the tags interface. Okay, so we’re still Team Bravo in this scenario. And let’s say we’ve just finished testing our build, so now we want to submit our library for approval. We see that Alpha has a library built to the staging environment in the submitted column, and since we know only one staging environment can exist per property, let’s try to submit it without building. But as you can see, we’re not allowed to do this. The submitted and approved columns can only have one library between them at a time which ensures that all upstream resource checks aren’t dealing with multiple libraries or potential conflicts. So for Bravo to move ahead, Alpha needs to move out of the submitted column on the options menu. We can do this either by rejecting the build, which moves it back to the development column or by approving it. Let’s just go with the ladder. We could choose to just approve it and move it to the next column, removing it from any staging environment and queuing the library up for publishing. But that would mean that Brava’s library would still be blocked from moving ahead. So instead, I will choose to approve and immediately publish as well. We can now move Team Bravo ahead, but note that we have to rebuild the library again, since approving Alpha’s library has caused a change in upstream resources when it comes to Alpha’s library. Now that it’s been published, it’s assigned to the production environment, and the previous production build has been removed in that environment while still remaining in the published column. Tags will keep all of your old production builds in the published column so they can still be viewed for future reference. But whenever a new library is published to production, the library that it supersedes is essentially deactivated. But let’s picture a worst case scenario where after we publish Alpha’s library, we find that it’s causing some critical bugs on the production version of our site. In this case, we can click into the options for the old production library and select Republish to effectively rollback the change to a previous state. Now the old library is once again the one that’s live on production and the new one has been disabled. Later on, if our teams find that the bugs were due to something outside of the tagging implementation and we’re able to resolve them, we can republish Alfa’s library back to the production environment. However, at the issues were caused by something in Team Alpha’s library. They won’t be able to change that library as production builds cannot be sent back to previous stages and the publishing flow Instead, Team Alpha would need to create a new library to move those updates to the same publishing flow from the beginning. Keep in mind that while all previously published libraries will remain available to view in the publishing column, only the five most recently published libraries can be rebuilt, which includes the currently published library. So before you commit to publishing a new library and permanently archiving your fifth most recent production build, always make sure that it’s been thoroughly tested and reviewed in your lower environments. So that was a basic rundown of how to manage, build and publish libraries and tags, enabling your teams to independently develop and test their tagging implementations while ensuring every iteration is fully compatible with all of your deployed tagging capabilities. Thanks for watching.