After reading a thread on the RedDot Google Group today, the first thought that came to my mind was “If I had to administer this project, I would shoot myself right in the head”:
Say good-bye to performance: This is a complete standstill system. I know, projects are often growing and evolving, but it’s always a good idea to plan a bit ahead – just in case.
License fees are money, I know. Same is true for the nerves and overall mental state of you CMS administrator. As your demands are growing for your web projects, it also may be a good idea to have a little more scope than the “three projects basic license”.
Create a technical master project for the development process. Your “live” website should be a child project using shared content classes from the master project. This also allows you to develop and test content classes without playing around with your live website where the editors are working. If the development of a new feature is finished, you can update your live project with a single click. For several similar projects (like country specific websites) I also create an empty template project with basic settings (e.g. resources, project setup, publication settings, common workflows). So setting up new child projects really becomes a snap. What’s good for content classes can’t be wrong for assets: If your projects all use the same look and feel, you can also share parts of the assets like layout pictures (e.g. icons, background images, images used in CSS files), mood and teaser images or common downloads. This reduces redundancy, increases clearness of the file structure and editors can easily re-use files. If you are hosting projects as ASP, you can apply these methods as well: Share common content classes and files as described above and store only the differences in the child projects:
Running projects on a single virtual server with your database stored on the same machine will get you in trouble way faster than you can say “Smart Edit” – trust me. The same setup on a physical machine won’t do a good job either. So keep track of your CPU horsepower and RAM. For large projects a server cluster is always a good idea: You can have several editorial servers and/or publishing server. This is also important if you have editors from around the world working on your CMS server: A full publication just before closing time in your U.S. office can be the reason for the massive frustration of your colleagues in Europe. With a cluster you can also avoid performance issues due to user peaks by assigning them to different editorial servers. This can also be changed on already running servers, which brings me to the last point:
It’s never too late to hope for salvation – most of the tips above can also be applied to already running projects. Of cause then you’ll have to be extra careful, so you don’t blow up everything. (Hint: Backups of projects and databases are your friends!) For example you can split an existing project while using content class sharing quite easily:
Set you plan first, check all the steps necessary, do all the backups (and make sure everything can be restored) and remember to communicate maintenance windows early to the users. Always calculate some extra time so you can restore a backup state in the worst case.
No related posts.