We are running a Production server for our content creators, and we do our development in a separate server, then move the changes over. On occasion (typically after a major publish from our production server) we will clone the production system and bring that back to our development box. We do this so that we are developing against real world expectations from the content creators. By having up-to-date content in our dev box, we can see when things are going to be broken by our changes (such as forgetting to xml encode special characters in an input field).
With our recent upgrade to 6.7 we now have access to the package manager, and I’ve been investigating how this might work for us, and after reading the 6.7 docs related to packages I have a few questions:
1)The package information (which design objects are currently in use in a package) is stored in the database, so when I clone our prod environment (the recipient of a package) and deploy that in our dev environment, the dev system will believe that it is the recipient of a package, rather than the originator. I’m thinking this will essentially destroy our ability to produce upgrades to a specific package, and instead, we will have to re-create a new package on the dev server each time we want to deploy updates to certain items. What is the best practice for development with multiple servers now that the package builder is available. I’m hoping I’m confused on how this works, but I’d just like to better understand the intentions of how the package manager should be used.
-
Is MSM still supported, and how do you decide which method is best for moving updated design objects? MSM has been very problematic in the past for us, in some cases it was easier to do manual moves of templates, content types, etc…
-
How are people handling shared objects with the package builder? For example, some content types and templates are shared between the websites we publish, while others are specific to that site. I believe it would be unwise to package them together, as it would force a code freeze any time you had shared items and site specific items in the same package, but needing different release dates. On the other hand, separating everything out could result in having dozens of packages, making it difficult to know which package to begin with when creating an upgrade. Is there a good way of compartmentalizing design objects in a way that multiple developers can easily remember where stuff should be located?
Thanks,
-Jason