tag:help-archives.hannonhill.com,2010-02-09:/discussions/how-do-i/13312-how-to-migrate-a-new-design-from-dev-to-prodCascade CMS: Discussion 2014-12-03T15:06:23Ztag:help-archives.hannonhill.com,2010-02-09:Comment/337254172014-07-11T21:30:16Z2014-07-11T21:30:16ZHow to migrate a new design from DEV to PROD<div><p>One other problem we ran into....</p>
<p>After copying the template, format and block folders over, we
discovered that the Metadata Set was still referencing the copied
site.</p>
<p>If we had changed the metadata set to the existing site first,
would that have prevented the links from being changed ?</p></div>jperreaulttag:help-archives.hannonhill.com,2010-02-09:Comment/337254172014-07-17T13:28:59Z2014-07-17T13:28:59ZHow to migrate a new design from DEV to PROD<div><p>Jeff,</p>
<p>I have been waiting to hear from Hannon Hill on how to solve the
problems you have run into. But so far there are no answers. I
believe that this is related to the nature of the problems. I do
not really understand exactly what causes the weird things. But I
may be able to offer you something to try out.</p>
<p>Long story short. I wanted to write a web service program to
synch two sites on two Cascade instances more than a year ago. Back
then, I did not have the ability to create assets, to relate one
asset to another, like attaching a block to a region of a template.
I tried some simple code and failed miserably. But now, I have
already built a library to deal with assets. I do have the ability
to return to the program I promised myself. I created a class named
<code>CascadeInstances</code> a few days ago, which can be used to
synch two sites on two instances. So far, I have succeeded in
synching seventeen types of assets: DataDefinitionBlock,
IndexBlock, FeedBlock, TextBlock, XmlBlock, ContentTypeContainer,
ContentType, DataDefinitionContainer, DataDefinition, Folder,
XsltFormat, ScriptFormat, MetadataSetContainer, MetadataSet,
PageConfigurationSetContainer, PageConfigurationSet, and Template.
These asset types can be synched separately. I have also tested
synching between two distinct Cascade instances, or two sites on
the same Cascade instance.</p>
<p>When synching assets between two instances, I pay special
attention to relating assets. For example, when synching a template
from the source site to the target site, I make sure that all
blocks and formats attached to the template in the source site are
either from the same source site, or from a different site on the
same source instance. Then I try to retrieve the corresponding
blocks and formats, either from the target site, or from a
different site on the target instance, and attach them to the
template in the target site. Cross-instance references are
impossible. When running into anything irregular, I will throw an
exception and flag the problem. This feature may help you clean up
the weird links between your two instances.</p>
<p>If you are interested, please let me know. I can give you the
partial classs so that you can try it out to fix the problems you
are facing on a test environment.</p>
<p>Wing</p></div>Wing Ming Chantag:help-archives.hannonhill.com,2010-02-09:Comment/337254172014-08-29T13:49:46Z2014-08-29T13:49:46ZHow to migrate a new design from DEV to PROD<div><p>Hi,</p>
<p>I need to better understand your approach to the redesign before
I can make suggestions.</p>
<p>When you went through the redesign did you have 1 to 1 match on
redesign page types to existing page types?<br>
Did you make a consideration for the content fields currently in
use?<br>
How many content types are you working with?</p>
<p>We have approached this a couple of ways. Our most popular
approach if you have the 1 to 1 match of current page types to
newly designed page types is to add a new output to the page with
the redesign. We will often set this to be not publishable or only
publishable to a dev server in the interim. This will require you
to update all of your current Configuration Sets to have the new
output. If there are variations of page content fields, we would
likely add this as an additional hidden field in the current Data
Definition. Once the design is set on all page types we may unhide
some of those fields to allow end users to customize the new
content areas. We have also written web services scripts to copy
and combine previously used fields into new fields.</p>
<p>I hope this makes sense. I am happy to discuss further. Please
let me know if you would like to do a call to discuss your exact
setup and our recommended processes. Or we can continue the
conversation here.</p>
<p>Thanks!</p></div>Pennytag:help-archives.hannonhill.com,2010-02-09:Comment/337254172014-09-07T09:10:36Z2014-09-07T09:10:36ZHow to migrate a new design from DEV to PROD<div><p>Penny wrote: "We have also written web services scripts to copy
and combine previously used fields into new fields."</p>
<p>Does HH have any examples posted of this kind of custom script?
Wing's awesome site has a lot of related example material, but I'd
love to see the HH approach.</p>
<p>Thanks!<br>
Jake</p></div>Jaketag:help-archives.hannonhill.com,2010-02-09:Comment/337254172014-11-11T19:18:16Z2014-11-11T19:18:16ZHow to migrate a new design from DEV to PROD<div><p>Hi Jake,</p>
<p>My apologies for the delayed response to your discussion, I was
going over some older discussions and noticed this one is still
open. Were you able to work through migrating Sites and mapping
data definition fields?</p>
<blockquote>
<p>Does HH have any examples posted of this kind of custom script?
Wing's awesome site has a lot of related example material, but I'd
love to see the HH approach.</p>
</blockquote>
<p>To my knowledge, we do not have any specific examples since the
code tends to be very specific to the client's setup. That being
said, if you are still looking for some example code, I can check
with the Services team to see if they have any code they can share
with you.</p>
<p>Please feel free to let us know if you have any other
questions.</p>
<p>Thanks!</p></div>Ryan Griffith