Introduction
The classical way of developing a TM1 Server seems to be to go in person to a customer site and develop on their infrastructure.
There are often many good reasons for this, mainly involving security and availability, but I have not worked this way for a long time.
I thought I’d post about my personal development methodologies and tools, and how they might help other developers in their work.
Local and Off-site Development
It’s first worth mentioning that I come from a software development background and have worked in various projects with different software development life-cycles, including structured Microsoft Consulting approach, “agile” development, and many variants in between.
This heavily affects my view of TM1 development, because I sometimes see practices that terrify me as a disciplined programmer.
I’ve seen teams of TM1 consultants developing individual models on their personal laptops, then trying to merge them together and integrated them in a completely unstructured way.
After seeing this, I certainly understand the appeal of the centralized dev server model.
However, I prefer a localized and often off-site development model for various reasons. It allows me to work on many projects simultaneously, stops frequent travel from interfering with productivity, can keep me free of untimely distractions, and just generally suits my way of working.
I won’t attempt to sell the approach here, as my focus is on tools and methods you can use if you happen to share my view.
My Process
Overview
Usually, the first thing I do when I start the development phase of a project is to find out whether it’s possible to work at least partially off-line.
If I find there’s a problem with sensitive data, I’ll just invent some test data in the initial development stages.
This also helps by providing independent, repeatable test cases that can be utilized for unit testing and possibly later for UAT.
I then work on a local TM1 instance on my laptop, whether on-site or not, which I have set up with all my standard tools and applications.
If data ever gets too big for the RAM on my machine, I’ll just scale back the data volumes.
Merging Changes
When the time comes, I’ll update the development server on the client site. I do this by performing an automated file compare and deciding which objects are new and should be included, and which objects should be left alone.
It’s easy to make this decision, as the file compare tool shows you exactly what has changed and which version is more recent. Most even allow you to do a visual comparison of text files, which is very handy for RUX and PRO files.
The tool I use for this is an open source one called “WinMerge”. You can check it out here.
Working in a Team
So, you might be thinking, this is all well and good if you’re working alone or on a very small team, but what about large collaborative projects?
Certainly, larger teams provide a challenge, but nothing that can’t be overcome.
Often in this case, it’s useful to “stub” the design. This involves creating all the cubes and dimensions first, and leaving out the attributes, rules, and TI processes. That way each team member knows what other cubes will be called and won’t make the mistake of creating any objects with the same name.
Naming conventions often come into play here, too. I will often turn up to a project and make it my first order of business to distribute a standard naming convention document I have been using for years. You might prefer a different convention, or the customer might mandate one, but the important part is everyone understands it and sticks to it.
I’ve attached a sample document I used on a project years ago.
Revision Control
One concept I find useful for projects with larger teams is revision control.
This is a discipline well known to computer programmers that not only allows your team to keep a centralized copy development files (in this case TM1 server files from your data folder), but keeps track of all previous versions, who changed them and why.
The Basics
The idea is to keep a central repository of all files in the project and allow developers to “check out” the files to their local computer and work locally.
Once they have made changes, they can choose to “commit” their files to the repository, or to “revert” the changes they have made. If other developers are also making changes, developers perform an “update” to ensure they have the latest committed files.
It has other benefits, such as allowing the team to “tag” releases, so they can always get back to a particular version of the project, and for an individual developer to “branch” development (split it), for experimentation or creating an alternate version.
There are many other features and benefits to using revision control, which you can find by doing a Google search on the topic.
If a revision control system detects that two users have changed the same file, it does not allow one user to overwrite another’s work. It gives a “conflict” notification and allows the users to deal with that conflict.
For text files, you can often “merge” the changes made to both files, or, since revision control tells you who made the conflicting change, you can simply get in contact with the other developer and negotiate which file is correct.
But for TM1?
It may seem counter-intuitive to use a revision control system for TM1, as many of the files are not text-based, but I have found it very useful. Sure, you lose the merge functionality for non-text files, but you can still often perform a Winmerge “diff” and get enough information to work out what has changed and how to resolve it.
When dealing with TM1, you can exclude the TM1 control files from the revision control repository, as most have an “ignore” feature. This is important, because TM1 updates these files each time the server is started up, so they will always register as modified.
The main drawback I have found is getting team members to adopt it, as it does require some process and training to be used effectively.
Software Options
The tool we also use for Flow development is called Subversion, with the Visual SVN Server front-end. It is an open-source version control system that supports all the features thus described, and a nice MMC snap-in interface for configuring the server and permissions.
There are also various front-ends for Subversion. The one we use is Tortoise SVN, which integrates with the Windows shell and provides icon overlays to indicate if a file is up-to-date or has modifications.
Conclusion
Using some of these techniques, processes and tools provides a more flexible project environment by making it easier for developers to work on local copies of their models and providing a framework to merge the changes back to the central server.
Of course, many of the free tools in the Flow Toolbox Suite have the same goal and can automate some of these concepts even further, to make TM1 development even easier!
If you haven’t checked out the tools yet, you can get them here.
I hope it has been an interesting and useful discussion. If you have any questions, feel free to comment below.