One of the main tasks I do as a Senior Notes/Domino consultant is fix/enhance existing applications. While I've been using templates since I started developing in Notes back in 1996, over the past several years the approach I've taken is to create a new template for each set of design changes under development.

If I've never touched the database before, and there is no existing template for the database, I make a copy of the production design as a baseline template. I give this baseline template a name of Service Requests Template (1.0) and a filename of serreqs-1_0.ntf. I change the production database properties so that it inherits from this template.

If I have worked on the database before, but its been a while and I can't verify if anyone has changed the design since I last changed it, I create the next template in the sequence using a copy of the current production db's design.

Then, I make a copy of the baseline or current template and increase the numbers: Service Requests Template (1.1) and a filename of serreqs-1_1.ntf. Finally, I create a copy of the production database to be used as the development environment, and change its properties to inherit from this new template.

This approach has several advantages:

1. I can test my design changes in a development database that inherits its design from the new template while the production database inherits its design from the current template. Sure, you can accomplish this without using templates, but unless you're making your changes to the live production database (a big no-no), you'll have to designate your dev db as a template and use it to refresh the design of the prod db. But if you do that and something goes wrong, how will you restore the prod db to its original design? If the problem is urgent, who has time to wait for the db to be restored from a backup tape? And what if a good backup doesn't exist?
2. I can make changes to a local replica of the template, instead of a local copy of the production database. This is very useful if the production database is several hundred mg, and I don't want to waste time making a local replica.
3. When it comes time to move the changes into production, all I need to do is change the design template name of the production database and let the Designer task make the changes for me overnight.
4. Opening a template with no documents is much faster than opening a local or server based replica of the actual production database.
5. Comparing design changes between templates using a product like TeamStudio Delta is a snap.

For an excellent discussion of using Notes design templates effectively, please see Darren Qualls article on the e-pro website.

I'll never forget the time when a customer told me that a view I had changed according to his requirements wasn't working. Since I had a copy of the design I last pushed into production, I was able to use Delta and determine how the view had been changed since I last put it into production. It turned out that the customer had changed the view himself, but "didn't remember" making a change. Instead of pulling an "I told you so", I asked if the customer wanted the view restored to the way it was originally implemented. Of course he did.

1. Chad02/18/2005 06:13:58 PM
Homepage: http://www.chadsmiley.com

The versioning of you templates is an interesting concept. You must change the template name so they are different for each version. The development environment (http://www.chadsmiley.com/chadsmiley/home.nsf/d6plinks/CHAY-68VS9D) that I work in is a little more strict and consistant. This is done so the template names do not change and the database design can be implemented off hours by the Design task on the server. I would be interested in your thoughts on this type of configuration.

Do you use Teamstudio CIAO!?

Chad

---

2. Michael Sobczak02/19/2005 06:34:04 PM
Homepage: http://www.punkdbynotes.com

I've used CIAO before, and its great tool. It allows you to store versions of individual design elements, point releases of a database (1.1, 1.2, etc.) as well as new versions of a database (1.0, 2.0), which is similar to what I discussed above. You still need to launch CIAO and tell it to store a new release or version of the database manually. The main difference is that CIAO stores all of the versions as attachments in a database, whereas I store all of the templates on the server itself. This may be preferable in some instances, where Notes administrators may not like their servers cluttered with a lot of unused templates.

Unfortunately, only two of the two-dozen customers I've worked for over the past six years used this product. That's why I recommend doing your own template versioning. Its definitely better than doing nothing at all.

In your environment, your production databases can only inherit from one template? If you can't change the design template name, can you still change the DB title and the filename itself? I'm wondering if you can have several NTFs for a production database, but where only one of them has a template name defined. That would allow you to do some sort of versioning.

---

3. Chad02/19/2005 11:27:26 PM
Homepage: http://www.chadsmiley.com

I would definitely say that we agree that templates should always be used for development. I think that there are many developers that still developed in databases. I was one of them when I started.

I agree any template versioning is good and I would agree with you that keeping the templates on the server and 'cluttering' them would be the best option, if I could not always use CIAO!. Here is what my environment would look like with using your version concept.

The templates would always been in every environment since the last migration. I would implement versioning by taking a copy of the template and place it in a different folder with a different database title, template name, and file name. This would be done before the new project development started, in the development environment. When the development was complete and was ready for migration it would move to through the environments to production. There would still only be on template environment, unless there was a need to have two different applications on different versions.

Here is a little more background on my approach: Every environment that I have worked in it has been very strict rules about touching anything in production so my goal is to make it as simple possible. That is why all versions would be in development and would have to get re-tested before any version would make it back into production again.

I do like your approach of versioning without CIAO!, it makes sense. Thanks for giving me some new ideas on versioning.

Chad

---

4. Malaga03/27/2005 10:05:49 AM
Homepage: http://www.demalaga.net/

Greetings from Malaga (Spain). Antonio

---