Need some advice/suggestions on version control of the modules developed under Application Designer.
We have a system in place to migrate and control the Natural program versions, but I would like to know what the best method is to control and promote versions of the code that is developed in Application designer. My organization owns and uses Star Team, but we would be open to any solution that works well and does not cost an arm and leg
I would think (not having done this before myself), is that one would have a development environment and a production environment and move WAR packages between the two. However, I sure there would be more to it than that…
To my mind there are 2 different aspects regarding version control:
Which version control system to choose.
The process how version control is done in the Team/Company.
During development I personally would like to check-in/out single files like single layouts, source code files, style-sheet files, image files… I would like to have versioning for each single file. This allows me to check the history for instance of a layout and compare different versions in the history.
If only complete .war files are checked in I usually cannot check the history of a specific layout file in a simple way.
I also prefer to check in/out sources and then do something like a nightly build or a “product version build” from the sources.
For Application Designer this means: Check in all the layouts, images, style-sheets…and then “build” the html-files and the corresponding .war file from these checked-in sources.
IMPORTANT: The Application Designer version used for the build and the Application Designer version in the production environment must match!
Regarding version control systems: To my mind there is not only 1 good version control system on the market. For PC environments there are also open source systems like CVS available. Which open source system to choose depends on the hardware/software infrastructure of the company, the processes, …and is to some extent also a matter of taste.
Thanks Christine for the detailed reply. So just to be sure - when you check in your code as you are developing, then you must check in all the different components like the HTML, XML, etc.? This seems a little manual but I understand the need for doing it this way. It would be nice to be able to version control a “screen” and all its components with one click. Oh well.
…about “check-in/check-out”-granularity:
In a developer team a version control system is usually not only used for keeping the version history but also to synchronize the work of the team members. A web-designer might do changes in style-sheet (.css) files and images, other team members might change the layout-files (.xml). All these files might belong to the same “screen”.
At development time it is very convenient to check-in/check-out single files. If only the complete .war file is checked-in/out, then only 1 team member can do changes at the same time.
For “frozen product versions” it might be different. Here you might additionally check-in the frozen product as a whole.
…about version control system integration:
How convenient the “check-in/check-out” is, is a matter of the version control system integration. Although multiple files are checked-in/checked-out it still can be just a single click.
Eclipse for instance has very good support for CVS. Using the Application Designer Plugins, Eclipse + CVS is one option. But there are others.
Independent of the version control system you are using: It is very important to check in the right files. I don’t recommend to check in the HTML-files! Application Designer generates these files and they depend on the Application Designer version.
The following files must be checked in:
Layout definition files (in the directory \xml), except the file ZZZZZGenerated.xml;
Help resources (underneath the directory \help);
Multi-language (internationalization) resources (underneath the directory \multilanguage);
Any other resources that you use in your layouts, such as images or styles.
Using for instance Eclipse+CVS you can simply use .cvsignore files to skip all other files and then check in a complete project.