Tealium iQ Version Control

Bronze Contributor
Bronze Contributor

Hi all, 

We currently have 5 people working in our Tealium iQ setup. Therefore, we are looking to improve out branching / versioning strategy.

"Merging Versions" feature seemed really nice. We decided to create a "master version", similar to a e.g. "master" branch in github :) And then we would create a separate version for each feature that we develop in Tealium. Once a feature is production ready, we would merge that feature version into "master version" and then release "master version" in the end of a sprint. However, our idea fall apart when we noticed that "Merging Versions" is not supporting Profile Inheritance (Libraris), that we heavily utilize.

Does anyone has best practices to share when it come to versioning / release strategy covering a fairly big team working in the same Tealium setup?

2 REPLIES 2

Tealium iQ Version Control

Tealium Expert
Tealium Expert

Yeah, like, this used to deeply upset me that I couldn't do cool branching stuff while still supporting library inheritance, but in a sense I think it sends the right message, which is that library inheritance sits in complete opposition to meaningful version control.

I'm not saying it would be impossible to blend the two things together, but fundamentally when you work with library inheritance you give up the ability to roll back changes in a straightforward fashion because the changes in question might sit within one or more inherited libraries, and rollback involves going into each, rolling those back, and then going back and republishing your main profile, and it's not that you can't do that, you just can't do it while holding in your head the belief that you're doing effective version control.

Essentially, what it then boils down to is how to adopt one pattern whilst retaining as many of the benefits of the other as possible. In my case, that's been to keep library inheritance but to offload more of the TIQ work to JS extensions whose code can be managed in Git and either pasted, loaded via the UI integration with Github, or via the new profile update APIs. It doesn't give you the ability to encapsulate interface-level config (such as tags and load rules) into a branch with your code, but if the bulk of the complexity of a large deliverable sits within JS extensions, it gets you at least part-way there to version control and delivery of completed features into a main branch.

The inverse then of that is to run with monolithic profiles and to find ways of separating and potentially reusing components using methods other than library inheritance. There's a sort-of-undocumented Automator tool that can do some of the heavy lifting if you needed a given component to be present in multiple published profiles that would allow you to master it in one place and programmatically copy it to others, which at least starts to solve for the "build once, use in many places" feature of library inheritance. The user access rights angle is harder to replicate - in my head, I've got this idea that you could hypothetically retain child libraries with specific access rights, and then use the various APIs and tools available to take snapshots of those libraries and insert them into a main profile that's not linked to them within TIQ but which would effectively inherit those configurations via that copying process. I could imagine that adding a whole heap of tech debt to your implementation, creating awkward dependencies on non-standard automations that make it harder for Tealium (and colleagues) to support your setup, and creating some potentially uncomfortable dependencies on very specific API methods that aren't guaranteed to work forever.

So like, no easy answers. For my part, I really like turning everything into pure JS and then mastering it via Git, and treating version control and branching as something that's done upstream of TIQ itself. But if you use a lot of the interface-led extensions or need to bundle tags, load rules, UDO elements and extensions into overarching branches, it's not going to work out so well..

Tealium iQ Version Control

Bronze Contributor
Bronze Contributor

Hi UnknownJ,

Thanks for your great reply, it is exprimily helpful for me since I am new to TIQ.
All the options that you have mentioned are essentialy good in their own ways, but might not produce the desired outcome for all types of teams though, but that is also what you say in the end of your comment.

I personally very much like the github/JS/Extension approach. However, one of our key objectives is to simplify our TIQ setup, and one of the ways to do it in our case is to reduce JS complexity, so that less tech savy team members and stakeholders can also deliver in an efficient way. And for the same reason, I believe that creating a custom sollution for library inheritance might not solve our core challenges. 

We are currently working on consolidating out multi-profile setup into just few profiles. This might be a good opportunity for us to re-think our libraries and the need for them. But that would be a tough decision, since libraries have quite few advantages such as separation of concerns, inheritance etc. 




 

Public