Best practices - deployment
Best practices - deployment
This document covers the best practices for deploying Plone solutions using Enfold software in your enterprise. No one document will be able to cover every conceivable situation but this covers some of the key cases and provides pointers to further information.
See also: Users and Security Reference Guide and Enfold Server FAQ).
Increasing the Frequency of Backups
When you install Enfold Server, you will usually choose scheduled tasks (which are run in the background by the service user).
However, the frequency for these scheduled tasks are conservative; you may choose to make them more frequent. For example, default settings for backups are once per week. That may be appropriate if you are already using mirroring and intend this as a secondary backup. However, if it is a primary backup solution, backing up once per day might be more typical.
Configuring Ports
See the topic changing ports .
Typical setups
Basic Setup
- One Windows server, containing Enfold Server
- One Windows server, containing the "front-end" web server with proxy. On Windows setups this is typically IIS + Enfold Proxy, but Apache and Squid may also be used.
- A standard Windows Active Directory environment, used by Enfold Server (and possibly the front-end server) for all user management.
Intermediate Setup (reduces server load)
- One Windows Server with both Enfold Server Enfold Proxy
- One Windows Server containing Enfold Server only.
The advantage of having two separate installs of Enfold Server on separate boxes is if you use one machine to perform heavy administrative tasks on the ZODB, performance on the second production machine will be unaffected. This is also helpful for redundancy. See also Using Enfold Server on multiple machines
In many sites there is normally a mirror of this for testing and development, but if there are insufficient resources to keep a complete mirror, the following is often used:
- One dedicated test machine containing both Enfold Server and the front end server
- The live Active Directory environment, with extreme care taken during testing.
We are also assuming that you've written custom code for your site, such as custom skins, content types and the like. These are written on the file system. Note: Making custom changes to the ZMI can cause confusion for deployment. Sometimes it will be necessary, but as a best practice, this should be kept to a minimum. The reasons for this are discussed in Plone.org's online documentation.
Once you have made changes to the development version, how do you roll them over to the live instances? This will be covered in the next section; but first, it's important to know exactly what is being deployed. Normally you will need to gather this information:
- new versions of Enfold Server software
- custom code changes for your site
- configuration changes in the ZODB or on the file system
The next two sections will cover to roll these changes out into production.
Rolling out changes
Installing custom code changes
All custom changes should be in separate directories on the file system. To deploy these to your production machine, copy the new code onto the production server and restart the Client (using Enfold Server Configuration Utility). The new code will now be live. Normally this can be done via whatever source code system you use internally, or through distribution of zip files.
Installing configuration changes
Unfortunately this is a little more tricky. You cannot easily copy over the parts of the database that you need to change. Likewise, the configuration file for the production server will use different paths and users from the development server. That means you need to adjust the settings as necessary when moving into production.
In both cases you normally have to make incremental manual changes. To do this, it is necessary to document every change that you make to the database so these can be reproduced. The more advanced developers would script every single Zope database change and then run those changes as a script on the production server.
Things to watch out for
When developing for Plone, people need to be mindful of security issues and changing integration points.
In many cases moving to a production server means a whole series of new usernames and passwords, or that various services and access points now have new security. This could cause things to break. The setup described above assumes you have one Active Directory server. What if you had two AD servers(one for testing and one for production)? That may require extra attention and documentation to get it right.
Changing integration points is another potential complication. If you had a relational database you might have two databases, one in production and one in development. You have to be mindful that when you deploy, you have to remember to change these settings.
Most of the time these settings are stored on objects in Zope which are in turn stored in the Zope database. Once these changes have been made, you do not need to repeat them on each code deployment, they will live inside the Zope database. You just have to remember that you rolled out a particular feature using your Zope database.