Just Enough Governance for Notes Blog :: Teamstudio's Dirty Little Secret

Bookmark :

Those who know us know that we are all about template based development. Because you know that it is the process of giving the template to the admin to update design that relieves us developers from any responsibility to making changes in production. But you know what? We don't actually develop on templates. I know--what hypocrites! Here's the whole story. An NTF file has size limitations that an NSF file doesn't, scheduled agents in NTF's are ignored, and you can't preview anything in an NTF with a web browser. So, rather than make changes to an NTF, refresh the design of our development copy of the NSF, go back to the NTF to fix what we didn't get right (it might happen!), refresh the design again... we just do our development in the NSF.

But here is the key part--when we are done with our development and are ready to hand it over to test, we make a new copy of our NSF, just copy design (no documents), and we name the file whatever.NTF. We just created a template! And check this out - our NTF doesn't claim to be a template! This avoids the whole issue of multiple databases 'claiming' to be a template. But it does allow us to REPLACE the design of the database we are testing. That's because the Replace Design dialog shows all NTF's, regardless of where they are on the system or whether they claim to be a template. Refresh Design, and the server based design task, both rely on the database saying it gets it's design from a template.

So we really are doing template based development, without using templates--sort of. Now, if only there were a tool to automate this process...

Comments

1 - Hmm... sounds overly complicated. Why not just do your development on a Development NSF and designate it as a template in the database properties? You can then have the Production NSF pull its design from the Development NSF template.

Posted by Adam At 04:17:14 PM On 03/06/2008 | - Website - |

2 - This is exactly how I do my development, in an .NSF and then when ready to package I make a copy as a .NTF and remove docs and fixup the ACL.

One major reason for doing this that you missed is that .ntf's are not served by the domino server to web browsers so doing web development is not that easy without the .nsf extention.

Posted by Declan Lynch At 04:18:03 PM On 03/06/2008 | - Website - |

3 - I have to go with Adam. Very complicated. We develop in .NSF files that are marked as Master templates. The name of those Master templates use this format : "ApplicationName releaseNumber".

Example : Help desk r1.3m1

So when or DevTeam is done, they only sent the Master template string to the Admins and then these guys replace the Inerited template name in the production Application and Refresh from the development server.

This way we kept a copy of every release on the development server.

Hope this will help.

Posted by Pierre Lalonde At 04:55:46 PM On 03/06/2008 | - Website - |

4 - @3 - Thanks for your comment, I do know some people who manage their versions this way. To, me, changing the template name that the database inherits it's design from for every version is more prone to errors than simply doing a replace design. And it does help in either case to have automated tools to make either method repeatable.

Posted by John Kingsley At 10:57:04 AM On 03/10/2008 | - Website - |

5 - Also agree with Adam. The described procedure only overcomplicates the release process. And where is the advantage of Lotus Notes/Domino gone that allows to only refresh the design elements that have changed. Remote users on dial-up connections (I know they rarely ever exist any more these days but I had to find a good example) would certainly appreciate not to download the whole template again just because a shared actions has changed.

Posted by Christian Petters At 08:08:40 PM On 03/10/2008 | - Website - |

6 - @1 - Not sure what you have said changes anything in the post. The only difference is that there is no NTF. Is that the over complication?
This maybe fine if the production database and the development template are on two different servers, but what if you need the design on the production server so the design task can keep everything right? Or you have a situation where development and production are not cross certified?

@5 - I agree I think you should be refreshing in production. I don't think that the post meant to imply that. However, in TEST, I think a replace is very important.

Generally regarding the template name, you get into problems if you are setting the template name in dev when you are trying to do parallel development ( fixing version 1 and working on version 2). Not setting the template name fixes this since you won't have to worry about the server fixing it for you. Also, putting the version number in the template name is a bad idea in the long run. As John said, this creates a situation where you have to update the database to reflect the right name. This may be fine if there will only ever be one NSF for each NTF, but it is a very bad problem if there are ever more than one NSF.

Posted by Craig Schumann At 06:39:21 AM On 03/11/2008 | - Website - |

7 - @6 Just answering your question about a good way to automate the process: File -> Application -> Refresh Design.

I just can't think of a good reason to use an NTF as part of the development lifecycle. It isn't a bad way to send code to customers - but I can't think of another reason.

Sure if you have two separate domains - and servers aren't cross certified that could be a pain. But if your user id was cross certified - would be all set.

Regarding the design task. Having the server do code changes for you at 2 in the morning is just asking for trouble. I always remove it from the NOTES.INI and put a SetupLeaveServerTasks=1 in there so it does creep back in during an upgrade.

Posted by Adam Fenstermaker At 10:04:25 PM On 03/13/2008 | - Website - |

8 - @7 - My point about the automated process was more about the stuff you have to do before that, sign the database, compile LotusScript, setting the proper agent settings like enabled/disabled, and run on server - stuff like that.

I'm fine with not using something with a file extension of NTF. However, depending on your environment these are essential.
The work that I do is purely as developer, and I send the template to the admin to be rolled out to the production servers. He gets an actual NTF that he can put out there. Have a hard dependency back to a template in my development environment wouldn't not work because I am prevented from continuing to work on the next set of changes until he has gotten around to pushing the new design out.
We also use the design task to automate the process of updating the production apps and making sure the design is always up to date. If the server is well maintained, there is no reason not to use the design task.
Depending on the size and complexity of the environment, there are lots of benefits to using both these mechanisms.

Posted by Craig Schumann At 06:15:36 AM On 03/14/2008 | - Website - |

9 - @8 - Maybe this would be a good feature for CIAO - spit out a release NTF (or NSF Emoticon

) using a build number.