How to survive off-days….

Disaster days and how to handle them.

We all know them…. disaster days. Mostly they are already starting bad. Like cars that don’t start, public transportation that strikes. Rain that pours, people shouting at you for no obvious reason. That is a day where you should not have ignored the signs and have stayed at home in your bed. Sometimes this just happen “out-of-the-blue” sometimes it is self-inflicted while you suffer from an overdose of “cool party last night”

But no, we are tough. We persist and fight our way through the day. But the real surprise comes next day when everything is working OK until you check last days work….. This is the point where you start thinking about Configuration Management Systems or at least Source Code Control…. Too late, you should have done that before…;-)

Yeah Right….

Making a zip file from your working directory every day is a solution, (and definitely better then nothing) but there are better solutions, certainly if you are not alone in your company.

Source Code Control is very old, on Unix Systems this is been used since there are Unix Systems. In the personal computer area this is a bit newer but also used a long time. The last 10 years or so, many people use Subversion (SVN) or Git, sometimes still CVS. All these are open source systems, you can just download them and use them. Since millions of people have, these systems are good, very good.

Of course there are still commercial systems that cost money, sometimes a lot of money. That does not make them better than SVN just different and they have a phone number that you can call when things don’t work.

More then a backup

Config Management does so much more than just saving you from bad days, it helps you preserve versions and releases, it helps you cooperate with colleagues and prevent changing the same stuff twice (the first one in is out….)
Modern systems use automatic difference/merge tools that are pretty intelligent and can merge files that are edited by 2 persons. As long as not the exact same things are changed, these tools do a good job.

What does this has to do with Rhapsody?

Everything…. If you develop with Rhapsody you also want to preserve stuff, cooperate with co-workers and much more.
And… no…. you don’t just take the source code and put that in CM, the model contains much more information then just the generated source code. In fact, the code can be generated from the model ALWAYS. (In fact it is Object code…) so don’t bother checking that in. (Only if you don’t trust Rhapsody…. or if you want to speed things up.)
Yes! You put the model under CM’s control. Now how is that done?
Rhapsody does not have a CM System built-in, it uses either the good old command-line or the a bit better and a bit less old SCC, the Microsoft Source Code Control. The latter is a registered DLL that is called by Windows. Works faster (although hardly noticeable on modern computers) but much nicer then command-line.
Unfortunately neither CVS, nor SVN nor GIT know SCC… there have been tools to create an SCC Interface, PushOK and TamTam but both have been discontinued for years (and PushOK is Russian, used to be a problem in the US but that might have changed….)
Luckily we have created a profile for the use of SVN via command-line. It is included in all Willert adapters but if you want it: send me a mail, i will send it to you.

What do we CM then?

Units. What are units? That are files that Rhapsody uses to store its models. A Rhapsody model is not just one file, per default the base model file (.rpy), all packages (.sbs) and Components (.cmp) are stored in files. Since all CM systems are filed base, this is the only thing they can process in CM.
You can use properties to tell Rhapsody to store diagrams in units and you can even tell Rhapsody that a Class is a Unit (right click, create Unit) but I do not recommend that. It is a sign of bad design if you need Classes to be units.

How is the Workflow?

There are 2 possible workflows

• Old-fashioned lock and free
  Once checked in CM the model is read-only until you check-out your “unit”. This is then locked for all others until you check it in again.
  In that way nobody can accidentally overwrite stuff that others have made.
• Work and Merge
  All members of the team have a copy of the model, they all work on it until happy, then use the (included) DiffMerge Tool to merge the changes in the base version. There is more risk that people are changing the same model elements but many of these changes can be automerged back.

Which is the best workflow? As usually: that depends. On how you work, with how many people and more. Also on how you have built-up your model, do you have one large model? Or do have divided into multiple models? In one of the next BLOG entries I will write more about methods to split the model up in smaller models.

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)