Export / Import a webproject

[boneill]

What is the process for packaging up everything in a webproject and exporting it so that it can be imported into another alfresco wcm instance.  I need to do this so that I can move a build through the Dev / Test / Prod environments which all will be on different servers.  The export should include all of the necessary web forms for the web project and all content that is in staging.  The content in staging that is imported into the new repository must be linked to the correct web forms in the new repository after the import. 

Many thanks in advance.

[pmonks]

For destructive transfers, backup / restore (http://wiki.alfresco.com/wiki/Backup_and_Restore) is the easiest way to transfer everything.  Even if you don't need everything moved over, this is often the best way to seed the target environment, followed up by a sweep to clean out anything that isn't needed in the target.

Cheers,
Peter

[boneill]

What about for incremental updates to a webproject.  For example, a new set of web forms that is linked to content imported into an existing alfresco test server.

[tommorris]

I find this an absolute pain.
Have a look at this thread. It might be helpful.
http://forums.alfresco.com/en/viewtopic.php?f=29&t=10727
Tom

[tommorris]

Actually, while I notice Peter online…
Did I see the appearance in version 2.2 of the 'acp import' action in the folder-details pane?
It could be just the installation I was looking at - It's been hacked around a bit.
Is there any plan for a corresponding ACP export?

Cheers,
Tom

[pmonks]

What about for incremental updates to a webproject.  For example, a new set of web forms that is linked to content imported into an existing alfresco test server.

For starters I wouldn't recommend importing content into a test server.  The authoring instance in your production environment is the system of record for content, and that's where content should be created and QAed (however that occurs - manually, via import processes, wotnot).  Having separate environments for development and QA of content is a legacy of traditional (pre-WCMS) content management approaches and doesn't really make sense once a CMS is in the picture.

That said, development and QA environments do still make sense when a CMS is in place, however they're used for managing the code production and QA process (which is basically independent of the content production and QA process).  In the case of code, the system of record is a source code management system of some kind, and the various environments (developer sandboxes, integration test, system test, UAT, etc.) are roughly equivalent to the sandboxes in the authoring system on the content side of the house.

Now the differentiation between code and content can be a grey area in some cases, but the rule of thumb I use is that code comprises the assets created by developers (techie folks), while content comprises the assets created by content contributors (business folks).  By that measure Web Forms are (in the vast majority of cases) code and should be managed as such (stored in an SCM, QAed in various developer and test environments, etc. etc.), whereas the content created via those Web Forms is content and should be managed as such (stored in the authoring instance of the production environment, QAed in user and workflow sandboxes, etc. etc.).

So the upshot is that your Web Forms would follow a completely different process to the content created via that Web Form - they would need to be manually (and incrementally) staged through your various development and test environments to production, and once they're in production they can be used by content contributors to create real, live production content.

How you perform the staging of the Web Forms is up to you - I've seen both manual migration (which is quick and easy, but does introduce potential for misconfiguration) as well as ACP based migration (which is a little more involved, but eliminates the risk of misconfiguration mistakes).  Regardless of how you do it, the issues alluded to in some of the replies here are moot - those only occur if you're using dev and test environments inappropriately ie. for content QA instead of purely for code QA.

Cheers,
Peter

[tommorris]

Thanks for the reply Peter, that's helpful. I'm sure you're right about me using environments inappropriately.

Sadly, some situations do require that web-projects are portable across servers.
I'm happy with the complete backup-restore approach, except when I only need to replicate a particular web-project, not everything else in the ADM and AVM too (for obvious reasons).
So that leaves me with using test content not the the real content, as you rightly recommend. So, no need to replicate XML content, which of course is ideal.
However, this isn't always useful in a support-environment (or some QA situations), because some problems are only experienced with production content. Quite often, this problematic 'live' content is either TinyMCE generated content (which can expose errors in the CSS) or web-forms that generate data used to drive behaviour (not just presentation).

Incidentally, a number of engineers use/used the XML re-association tool (mentioned in the thread link I posted), and recommended it, so it can't be all bad.

But ultimately, I do agree with you whole-heartedly. Good response.