A Recommended Notes Development Environment: Part 1
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)
- 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)
- 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.
Category Best Practices
| Permalink |
|
|
|
|
|
Comments
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 - |
Posted by John Coolidge At 03:10:18 PM On 11/01/2007 | - Website - |
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 - |
Posted by BV At 01:48:59 PM On 11/29/2007 | - Website - |
Posted by Larry Gearing At 12:19:48 PM On 04/03/2008 | - Website - |
Do you work with TeamStudio CIAO! How would you apply that product to the diagram you have provided? Can it be used to both watch changes to the Development nsf and the promotion of templates? Recommendations?
Thank you.
Posted by Larry Gearing At 01:06:53 PM On 02/22/2009 | - Website - |
Yes CIAO will work in both cases you have mentioned. It does watch the design as well as have basic promotion capabilities.
Feel free to contact me off-line if you need more help
John
Posted by John Coolidge At 09:15:47 AM On 02/23/2009 | - Website - |
Posted by Larry Gearing At 05:18:05 PM On 02/25/2009 | - Website - |
Just wondering if anyone else has experience of similar working practises and also wondering if there are any Data Sanitizing products available to randomize the Personal&Confidential data contained in a database?
Posted by steve At 08:37:58 AM On 04/09/2009 | - Website - |
@Steve. Personal/Confidential data is not recommended. This is fairly common. I have written agents in the past to "sanitize the data" they are not too hard to create. as for Live data that is not as above, I think is fine, less work for me and I get truer results in testing. Again only If it is NOT confidential or personal.
Feel free to contact me to speak about it
John
Posted by John Coolidge At 09:02:03 AM On 04/09/2009 | - Website - |
We solved that problem rather easily though, but randomly sorting each column of data and reloading it into our test system. This allowed us to quickly get a lot of data without having to create it. It was mixed up enough to remove any chance of identifying real company information. We even added records from our prospect database so you couldn't even be sure you were identifying a customer. Easy solution to what could have been a very ugly situation. And if that happened today, I'm sure it would be a lot uglier, and most likely more expensive than it turned out to be for us then.
Scott
Posted by Scott Johnsen At 03:34:17 PM On 04/09/2009 | - Website - |