Before we begin, let's put into perspective the effort we are about to undertake. Everything you learn in this book is intended to make you a better Plone site administrator.
In order to disseminate the subject matter, we will divide the site administrator's tasks into three categories:
Development
Deployment
Maintenance
Development usually begins with a buildout configuration file checked into a software repository. Initially, this buildout creates a software stack suitable for running the desired version of Plone.
Using this buildout, any developer can join the development team quickly and gain speed fairly easily. As the site administrator, you may be doing some, all, or none of the coding for your site, but you should still be familiar with the process.
Development tasks usually consist of:
Creation of a policy package: It is necessary for performing various site customizations. Policy in this context usually means: "applies project-specific customizations or features". See Chapter 5 of "Professional Plone Development", Martin Aspeli, Packt Publishing ( https://www.packtpub.com/Professional-Plone-web-applications-CMS/book) for more information.
Theme development: Traditionally, themes are implemented within a theme package that contains CSS and JavaScript files, images, and so on. More recently, you may see Deliverance or XDV-based themes being used (outside of Plone). See "Plone 3 Theming", Veda Williams, Packt Publishing ( https://www.packtpub.com/plone-3-theming-create-flexible-powerful-professional-templates/book) for more information.
Adding features: In addition to customizing Plone's default features, you may need to add new features as well. You can do this by installing existing add-ons or developing new features from scratch.
Writing tests: Unless you want to click through your site every time you make a code change to make sure that everything still works properly, you will want to write the tests—you will want to write lots of tests. In addition to the practical aspects of testing, good test coverage is a strong indicator of a job well done. See: http://plone.org/documentation/kb/testing for more information.
Eric S. Raymond (http://catb.org/~esr/), besides being a well-known open source advocate, is also well-known for this statement (http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html):
"Release early. Release often. And listen to your customers."
This sentiment is not lost on the professional Plone site administrator. The sooner you can deploy a basic set of features to staging, the happier your client or boss is going to be. Deployment steps usually consist of:
These are the tasks that no one wants to perform, but that everyone will blame you for not doing whenever they are not done. Fortunately, we can automate most of these:
Pack the database
Rotate logs
Back up the site
Monitor performance
The following diagram illustrates the typical workflow associated with these tasks:
In the diagram above, you will notice three workflow states—development, deployment, and maintenance. We describe the common transitions between each of these states as follows:
Development to deployment: During development, a project buildout is created. Not long after that, it may be deployed to staging for testing. It is not uncommon to deploy to staging many times before deploying to production.
Deployment to maintenance: Eventually, after development is complete, deployment to production occurs. Once you deploy to production, proper maintenance becomes critical.
Maintenance to development: After some time in production (with regularly-scheduled maintenance), more development may be required to fix bugs or add new features. Eventually, the development costs may outweigh the return on investment, at which point you are approaching the end of life.
Do not take this too literally; it is just meant to provide some perspective and a glimpse into the cyclical nature of Plone site administration.