Domino Development Part 1 - Environments
Bookmark :
Going back, way back. OK, not that far back. I would like to back up a little to lay the foundation for some tools and modules that I would like to present to you for Domino Development. First things first Environments! If I could have the ideal Domino configuration it would look and work like this:
Yes, the configuration seems simple and I would think it is close to what the typical Domino configuration might be. There might not be as many environments, but there is always that money issue. I am curious what other type of configuration people use. I did some searching on Domino environments and only found Martin Scott's - Notes/Domino development version control strategy.
Now that we are back at the beginning, about 9 years ago. I originally started out doing my development in databases and creating templates from them. The template would then migrate through the environments, but always had problems when the template migrated. The best thing I ever did was to create a template for each application in development and use that for development and migration. Which caused a little more work during development but was a life(job) saver. There is not one big reason to have the template development, but many little advantages that added up.
Here are some areas to consider:
Going back, way back. OK, not that far back. I would like to back up a little to lay the foundation for some tools and modules that I would like to present to you for Domino Development. First things first Environments! If I could have the ideal Domino configuration it would look and work like this:
Yes, the configuration seems simple and I would think it is close to what the typical Domino configuration might be. There might not be as many environments, but there is always that money issue. I am curious what other type of configuration people use. I did some searching on Domino environments and only found Martin Scott's - Notes/Domino development version control strategy.
Now that we are back at the beginning, about 9 years ago. I originally started out doing my development in databases and creating templates from them. The template would then migrate through the environments, but always had problems when the template migrated. The best thing I ever did was to create a template for each application in development and use that for development and migration. Which caused a little more work during development but was a life(job) saver. There is not one big reason to have the template development, but many little advantages that added up.
Here are some areas to consider:
Access Control List
Hopefully your are not asking yourself what ACL has to do with design? I found that the ACL in databases should be different than templates. The biggest reason is the use of brackets. When a database is created from a template any ACL entry on the template that starts with [ and ends with ] will be copied to the new database without the brackets.The second is better ACL on templates. As I stated, when I was done development I would make a copy of the database to create the template. I would always select the option to copy the ACL to get the roles and servers so I would not have to re-added them. That means all the extra ACL entries that where needed for testing where also brought along, like a test account.
If development is done in a template the ACL is set when it is created, or when the design requires new roles or access groups to be added. That is the only time that the ACL on a template should be touched. The ACL on your template is part of your documentation. Each entry listed is what the application is anticipating for users. Here is what the would look like:
| Entry Name | Access | Roles |
| -Default- | No Access | no roles |
| [-Default-] | No Access | no roles |
| Anonymous | No Access | no roles |
| [Anonymous] | No Access | no roles |
| LocalDomainServers | Manager | all roles |
| [LocalDomainServers] | Manager | all roles |
| OtherDomainServers | No Access | no roles |
| [OtherDomainServers] | No Access | no roles |
| [Reader Group] | Reader | [Role1] |
| [Author Repsonse Group] | Author | [Role2] |
| [Editor Response Group] | Editor | [Role1],[Role2] |
| [Editor Main Group] | Editor | no roles |
| [Application Admin] | Editor | [Admin] |
| [Application God] | Editor | [Admin],[Role1],[Role2],[Role3] |
Documents
Just like the ACL, documents can be added to a new database from a template. The only way this is possible is to have those documents reside in the template when the database is created. These could be configuration documents, lookup or keyword documents, sequential counter document with the starting number set, or even profile documents.Design Inheritance
After creating a template from the database I would have to set the Template name to the same as it was in production, other wise the server's design task would not update the application. Yes, this has happened to me more times than I want to admit.Watch out for creating a new design element in a database that inherits at the database level. Each design element will have prohibit design refresh checked. When creating a new copy the prohibit design refresh will still be set in the new template. Once this flag is set in the template it will be refreshed in the database. This little flag will not surface and haunt you this time, but the next time there is a migration with a change to that design element. The production application design element is set to prohibit design refresh, so it will never be updated. Now don't go through your production applications and make sure that all design elements do not have this checked, because some design elements this is appropriate like views and agents.
I will be talking about inheritance more in Domino Development Part 2 - Library Templates.
There are two cons to with inheritance when developing in a template: File | Database | Refresh... and web testing. Every time that a design change is made to the template the database needs to be refreshed to test. This is not totally a con because it forced me to do better unit testing in the template first. It is possible to test the template in Notes, but a template can not be opened on the web, so the database has to get refreshed. The pro is having database inherit from the template, just like it is in production (of the little advantages this is the one of the biggest).
Consistency
Every environment is the same, one template and one or more databases using the template. When I designed the migration strategy at the last two companies that I have worked at this has been the easiest for newer developers to understand, because the template is only ever migrated. Since each environment was consistent I was able to follow some naming standards databases and templates.Templates:
Database Name: <Application Name> Template
Template Name: <Application Name> Template
Databases:
Development: <Application Name> Development
System Test: <Application Name> System
Q/A: <Application Name> QA
Production: <Application Name>
Database Flexibility
When development is done in a template the development database is just a database so it can be over written from Production or any other environment. Once the database is re-created the design can be replaced from the new template. Some configuration changes might be required depending on the application design (this will be a future article as well). This would allow the opportunity to have two or more databases using the same design. The best example of this would be an application database and an archive database. I use two different database to test the ACL because most entries are set to reader.Summary
Like I said there is no home run reason to use templates when developing, but for me it has eliminated many problems and provide more options. Here are what I see are the pros and cons for using a template in development:Pros
Cons
Check List Template Development
Comments
Posted by Michael Sobczak At 01:03:52 PM On 06/11/2007 | - Website - |
Here is a link: { Link }
Posted by Chad Schelfhout At 08:24:07 PM On 06/12/2007 | - Website - |