Just Enough Governance for Notes Blog :: A Recommended Notes Development Environment: Part 1

Bookmark :

In my last post, Application development in production anyone? I discussed the pitfalls of developing in production. Mike Wetherbee, in his post Lotus Notes Environments--One-Tier, Two-Tier, Three-Tiers and More! expanded on that and discussed Notes environments. I would like to take it further and explain what, in a perfect world, a Lotus Notes development environment should be. (more)

Three servers: (See image below) Development server:

Same Domino version and OS as production.
Should have a logical directory structure (I.E folder for source code, Sandbox folder for developers, etc)
Does not need to be as robust as production. (Could be partitioned with test server then hardware needs to be same as production).
Developers have full access to their own databases and templates on Dev server.
Administrators have full access to development databases and templates.
Should not be replicating with production (Except NAB if in same domain)

Test Server:

Same Domino version and OS as production.
Same directory structure and security as production.
Same hardware as production (May be partitioned with Dev server).
Developers editor access to production databases and no access to templates
Administrators have full access to production databases and templates.
Test users have the appropriate access to test the applications.
Should not be replicating with production. (Except NAB if in same domain)

Production Server:

Developers have no, or editor access to production databases and no access to templates.
Users have the appropriate access to the application.
Administrators have full access to production databases and templates.

This has always worked great for me, and it should for you as well. Feedback, suggestions, war stories are welcome. In part two I will discuss ways of moving code from dev to Production, and all the things to think about along the way.

Comments

1 - I would add a Pre-production environment when possible. It's not a must, but in my experience it would really help in the testing phase.

The problem lays on the creation and mantainance of the environments:
- Developers create the minimum amount of users needed to test their code. That is, all is configured to perform as expected.
- UAT contains all the users necessary to perform unit and integral tests, but rarely mimics the entire Production environment configuration.

Pre-production would solve this issue, but moving code to production would be an odyssey.

Posted by Pablo Barlow At 12:54:31 PM On 10/30/2007 | - Website - |

2 - HI Pablo thanks for your input. I must say I have seen UAT environments that do not match production, but that is why my recommendation is that the test environment MUST match, this is critical to ensure the application will function in production. Adding another environment just adds to the level of complexity, as you stated

Posted by John Coolidge At 03:10:18 PM On 11/01/2007 | - Website - |

3 - The post is great, concise, almost perfect.

About Test Vs. UAT i agree about the fact UAT is complex to achieve and that a test environment must match production.

When possibile when it's possibile i tend to take some production data to the test environment (so we also get the real complexity of production, not just test data).

So the process is:

1. Develop
2. Copy data from production to test
3. Apply template changes
4. Apply data updates trough upgrade agents
5. Test
6. Take into production template changes
7. apply data updates with the same upgrade agents.

Posted by Daniele Vistalli At 04:59:54 PM On 11/15/2007 | - Website - |

4 - Server/Domain cross certification does increase convenience, but it also diminishes the walls between the environments. My gut feeling is to make sure any dev or test environment is not trusted by production.

Posted by BV At 01:48:59 PM On 11/29/2007 | - Website - |