Domino/Lotus Notes Development, Test, and Production setup

Hello dennis_gardin,

http://www.redbooks.ibm.com/cgi-bin/searchsite.cgi?query=lotus+AND+domino+AND+administration
I found IBM's redbooks to be one of the better sources of documentation, although there are some very good books about Domino administration. If you can lay your hands on a Lotus Domino Admin manual, even an old one (R4 or R5), that would be excellent. The architecture hasn't changed much.

What's your background, how familiar are you with Notes and Domino?

Regards,
   Sjef

I'm a Lotus Notes Admin, with a cert in Dev. I am working as an Admin now. I have a dev that has just as much power. I would like to show managment that thier needs to be a process, before deploying and application into production.

This may not be exactly what you are looking for, but here is how I setup my environment.  It is easy to setup, easy to administer, and has worked extremely well for many years.

1 Development Server (DEV)

 - Contains design templates, tools, and resources.
 - This is where you do any design work.
 - The design template databases typically have a Template Name that contains the term "DEV".  For example, my project design template is called "ProjectsDev".
 - Located in a separate domain with a separate NAB to prevent any accidental update of production or test code.
 - The server is only accessed by developers and admins.  Typically, developers can create databases.

1 Test Server (TEST)

 - Contains test copies of the design templates that are stored on the DEV server.
 - These databases typically inherit their design from DEV.  For example, my test copy of the Projects database inherits from "ProjectsDev".
 - These databases are typically not replica copies of the production databases so that they can be tested independently.  The only exception in my environment is the NAB, which replicates fully with the production NAB so that I can use any group of users for testing.
 - Usually located in the same domain as your production server(s).
 - The server may be accessed by everyone who uses production servers, but developers can create databases.

1 or more Production Severs (PROD)

 - Contains production templates that inherit from the DEV templates and are called PROD templates.  For example, the Projects database template on this server would inherit from "ProjectsDev", and the Template Name would be "ProjectsProd".
 - Contains production databases that inherit from the PROD templates on the same server.  These are the databases that contain live data.  For example, the "IT Projects" database on this server would inherit from "ProjectsProd".  All other "Projects" databases on this server will also inherit from "ProjectsProd".
 - No design work should be done on this server.
 - The Designer task should be set to run nightly.
 - The server may be accessed by everyone.  Developers may or may not have access to create new databases.

Usage:

(1) Do all of your design work on the DEV server.
(2) When you want to test your design, select the TEST database on the TEST server and refresh the design from the DEV server.  This is the only way to get the design from DEV to TEST.  The manual step ensures that your TEST code is never updated until you are ready.
(3) When you are ready to update the live production databases, select the PROD template on the PROD server and refresh the design from the DEV server.  The live application database(s) will not be updated at this time, but will be staged for update by the Designer task that should be running on the PROD server.  When the design task runs, the design on the live production database(s) will be updated.  This is the only way to get the design from DEV to PROD.  The manual step ensures that your PROD code is never updated until you are ready.  The staged process of using the Designer task helps to ensure that design updates do not occur on live databases while users are still connected.

I would also check the Design CLient Help to see if they have a process for deploying applications there.
See application management.

Also , good practices are general for software development, not just for Lotus Notes, so you need a test Environment wher QA can be done before rolling it out to production.

I hope this helps !

I got sidetracked a little, I intended to post a lot earlier...

I'd say it all depends on the size of the application and the impact it will have on the organization (#of users, close to core process, etc.). Sometimes a development environment of just one PC will do, but in other cases a complete cluster would be required. Likewise for testing. So if you're building the all-in-one application for 30'000 people, you'd need at least 3 separate environments. You'd also need development tools (TeamStudio, Ytria), test tools (home-made, and Lotus?), deployment tools, maintenance tools, etc.

So, how "large" is your application??

Sorry, sjef, but I disagree.  I don't think that the size of an application should affect the design environment at all.  The separation of design and data is a fundamental design principle that too many Notes developers overlook.  Making a live code change with even 1 user connected to the smallest database can produce unpredictable results.  I'm probably too much of a perfectionist, but my goal is zero helpdesk calls on my behalf.

Now, I might agree that the size of the organization or budget may affect whether you want to invest in 3 servers (although I could argue that I can setup 3 separate environments on 1 machine).

I am just looking for a good model for my organization (Small 15 Servers)
i.e. how to promote from dev >> Test >> Prod

Bill, logically I agree with you, but the size of the real (physical) environments could be quite different. A single person in a one month development project wouldn't need to separate the environments physically. A test database, a development template and a production database would normally be enough. Sure, some guidelines are required, but I've done many a project like this. On the hardware side, even a laptop with all three clients and a Domino server installed can be enough during development.

Of course, in a large, multi-person development and maintenance project, multiple servers are required, and procedures, and expensive tools, etc.

Once again, in my opinion, size does matter... ;-))

H, Sjef.  Thanks for responding.

We're on the same page.  I never ment to insist that each environment needed its own server.  I was just describing how my environment is setup (which I still think is best if you have the resources).  In fact, I operated with all three environments on the same server for several years before getting my own dev and test servers.

A lot of Domino developers just develop locally, and only test on a server.  If the app isn't doing anything too weird with agents or external access (DLLs, SQL), and doesn;t work directly with your Domino Directory, then it may be feasible to run test copies of a database on a production server.  Your sequence is then:

1) Developer creates NTF and hands off to you
2) You create a new database or redesign an existing TEST database using the NTF
3) When the test is approved, YOU create a new NTF from the test copy and redeisgn prod

All the above also apply even if you have separate multi-server dev, multi-server test and multi-server prod environments!  The only difference woulud be that the NTF in step 1 is created off a working dev server instead, so theoretically, you coudl tajke the NTF directly instead of the developer giving it to you.

thing is, that relies on "no unknowns" or no bad guesses.  For example, the developer THOUGHT that the agents would never do anything to update 750,000 documents at once.  But it did.  And since it was tested on a prod box, that brought prod performace to its knees.

Or, he forgot that he installed a code library he found on OpenNTF that makes uses of external DLLs, and they crashed the server.

So, Bill is correct that if you can avoid it, you don't touch prod until tetsing has been completely cleared in a separate environment, at the very least, and ideally, you don't touch test without the developer first debugging (technical tetsing) the code in a separate dev environment.

ABOVE ALL!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! TWO THINGS:
1) Don't give developers better-than-regular-power-user access to prod or even test.
2) Dev, test, and prod DBs should never be replicas of each other, and even the NABs should be separate replica IDs.  This CAN make is harder for the developer to code sometimes (can't rely on knowing the replica ID of system databases, can't rely on replica IDs to tie together a suite of databases that work together).  That's a safety v. expediency issue... another version of the typical security cost v. quality tradeoff.

To set up the "ideal" environment:
1) Catalog all the unique "server types" inproduction (e.g., mail, app, hub, admin, smtp, integration)
2) Create a brand new admin server, using a new cert, first server setup, for dev
3) Add any unique server types the developer needs (in some cases, you can overlap functions, and in some cases, if you have, say, multiple app servers, you may need at least two of a type in dev)
4) Repeat #2 and #3 for a test envrionment
5) For the dev environment, give developers elevated privileges
6) For test, typically you will have the keys, not the developer, though there can be some flexibility

This sound like a lot?  Like I said, you can combine dev and test, and you often only need ONE server for dev to begin with, ONE server for test, and now they are combined.  That does leave you with a situation where you probably have to let developers have free reign over the complete dev/test environment, unless you want to give your developer bureaucratic headaches!