I am beginning to look at MSM, so I watched the webinar from June to get an idea . I was wondering if approaching MSM deployments with a more formal CM approach was feasible (CM from a process management perspective, like CMMI, ITIL, etc). More specifically, as I move archives to deployment targets, I’d want to logically group these archives and check them into a CM repository of some sort and tag them. Is that a feasible approach? Also, is it possible to crack open the archives and have a look at the CMS objects they contain? For instance, it was interested in seeing how a given template or slot looked at some point of a time, I’d want to able to do that.
Lastly, it was mentioned MSM did not provide a rollback feature. If one was interested in creating a rollback procedure, is taking a database backup and a filesystem backup of the Percussion install directory sufficient (provided you didn’t have external stuff going on, of course)? Most government agencies require you to have rollback procedures for any production deployment, so I want to be ready when the question is asked.
We run JIRA as a bug/task tracker, and we track every MSM archive as a “version” in JIRA. Our version naming scheme is [RX MAJOR VERSION].[RX MINOR VERSION].[RX POINT RELEASE].[RX PATCH NUMBER].[MSM INCREMENT AT THIS LEVEL]. In turn, we name our MSM archives to match this, so we can easily review our internal discussion, etc as they pertain to fixes in the archive. The MSM archives don’t lend themselves well to manual inspection, though you can change the file extension from .pda to .zip and open them up. A copy of your MSM archive is created in ~/Rhythmyx/sys_MultiServerManager/server/ExportArchives/. You also get the copy downloaded to your client machine. As for figuring out how a template/slot relationship looked at a particular time (based on the archive itself), I’m sure the data is in there, but have fun tracking through that. This is the reason we track such changes in a separate bug/task system so we can figure out why/how we changed something.
The MSM tool allows you to view the contents of a particular archive as it was deployed. Look under [db connection info] > [server name : port] > Target > Archives. That’ll show you every archive deployed to that server. You can drill down by right clicking on a particular archive and choose “View Log.”
As for rollback procedures… the only way that I’m aware of is a full database dump. Be sure you’ve shut down the application server before you take the backup; otherwise, you may run into problems with the data integrity and foreign keys. If available to you, depending on your database type and version, you may be able to “snapshot” your database or snapshot the filesystem the database is on. Since I don’t know your infrastructure, you’ll have to decide the fastest method. In our case, we’ve got about 48G of database storage, so it takes a while for us to create a dmp file and later restore from it (we’re talking hours). Don’t forget to take a snapshot of the filesystem too. Content types, shared fields, and system fields are dependent on XML files in the filesystem.
Also, beware of gotchas wrt MSM if you’re going to be running a development environment and refresh it from your production environment. There are files relevant to MSM archives in ~/Rhythmyx/sys_MultiServerManager/. You’ll also need to take a look at the DPL_ID_MAPPING table in your development environment after the refresh. If you know this will be an issue for you, just say, and I can attempt to spell out the details in a follow-up.
Thanks so much for responding; this is GREAT information. The more I learn about MSM the more I’m finding out that it’s going to be a more complex and nuanced than deployling, say, a Java or .NET web application. For the moment, I’m just getting ramped up and am going to try create some basic CMS objects (content types, templates and slots) and deploy them to a dev machine.
We are starting to get our feet wet with MSM and note from your posts and the documentation that there is no rollback in the event that a deployment to production results in a problem. This is a major issue for us and add a lot of risk.
Would it be possible to build an archive from PROD of the exact sames elements being deployed in the MSM from a DEV to a PROD environment? For example, if you want to deploy via MSM a group of 10 elements, you build an MSM archive in DEV with those 10 elements. You then build the same MSM archive of the ten element in PROD to act as a backup. You deploy the archive created in DEV to PROD. If issues, you deploy the archive you made in PROD before the change back to PROD.
Would this be a viable way to backout an MSM archive? Thanks.
This may help as a strategy with one exclusion. MSM does not remove any elements installed if you are installing an existing content type with a new template, rolling back this way would remove the relationship to the template but not the template itself, which may at least get the server working again. If the server is in a real bad state though the revert package may fail itself. Most of the time the errors are due to something missing in the destination server that was not packaged, in which case it is often easier to just repackage and reinstall all after updating the original descriptor.