Thought it’d be interesting to write out the things that stop me from using TM1 Git integration so far. There’s been a few discussions on tm1forums that highlight some of them:

• https://www.tm1forum.com/viewtopic.php?t=15298
• https://www.tm1forum.com/viewtopic.php?p=76082

and I wrote a couple a posts about it.

Most of this post is perfectly summed up in the single forum reply by lotsaram, feel free to read that and skip this post, I’m using it as a chance to state document why I stopped trying :)

Preface

I like version-control a lot (the blog you’re reading was published via a git push :) ) and use Git for any scripting outside of PA/TM1.

I also know / worked at a few TM1 projects that were large enough that version-control and deployment automation was necessary and it was built with Git, but without Git REST API integration functionality and with scripted copy objects to folder - push to git / pull from git - copy or patch objects to server mechanics instead.

So why people re-invent or ignore the ‘built-in’ git integration?

IBM design approach to Git integration

Gleaning the intended workflow from current Git integration concepts it feels like what IBM envisaged was:

• every developer has a separate tm1 server / model – as GitInit binds a single set of credentials for the whole server
• the model is treated as a single set of code - pulls and pushes work with the whole codebase by default
• whenever changes / bugfixes are required, current development state is stashed or branched and the whole model is pulled from production, fixed and pushed back

This is very different from the usual TM1 set up of:

• multiple developers working on multiple things in a single development server
• those multiple things would be in different state of readiness at any point of time
• bugs are replicated and fixed as part of the multiple things in the development pot
• once a feature or a bug fix is ready, the changed objects are extracted from development and promoted further (old-school stop \ copy \ start or some sort of hot promotion via reading the code & patching it)

The difficulty of selecting a specified set of objects in the current Rest Api calls prevents using them in this workflow. Yes you can craft clever project files to carve the required pieces out (I wrote about it), but it immediately goes into ‘too hard’ basket in practice.

Target audience and Git

The design problem above could be solved by everyone being extra dilligent, cherry-picking objects and creating custom commits with Git, but most TM1 developers are better at balancing a balance sheet than merge conflicts.

The level of Git proficiency required to work around the design limitations greatly exceeds the amount of time people are happy to spend on it. And as a guy who routinely messses every 7th of his git commits I’m fully not ready to try to force this cognitive burden on anyone.

And the problem exacerbated by the fact that none of the current tools includes this integration, so that everyone needs to

• manually create a project json file or run a script for it
• run some sort of script to prepare promotion branch on git and push to it
• run a script to deploy this promotion in a target environment

and those scripts need to be able to authenticate properly / have a place to be run from / have a good level of error handling and so on and so forth, so by the time you’re writing those it’s actually easier to DIY the whole promotion without touch Git Rest API calls :(