Deploying changes to different environments

Enonic version: 4.7.11
OS: OSX

Hi,

We work in an agile development environment, where we deploy changes to production several times a day. We change static assets, XSL files, content types, portlets, page templates, and content often.

Deploying static files like assets and XSL is not a big deal - we’ve created a shell script to rsync these. However - deploying database changes such as data sources and content types - as well as content - is still a manual, tedious and error-prone process. The result is large differences between our QA and production environments (not to mention differences between local environments) - which is not optimal in any way.

What is your preferred method of dealing with deployments between environments?

Hi, for 4.x we’ve created a process called GERM - https://enonic.com/docs/4.7/development-process---germ.html

For enonic xp this is dramatically simplified :slight_smile:

Hihi, guessing you weren’t super happy with the 4.x way of doing it based on the name. :smile:

Yeah I’m looking into XP now, seems much easier :thumbsup:

I’ll look into the GERM way then :wink: Thanks for the quick reply!

However, GERM doesn’t handle Content, ContentTypes, or DataSources.

Is there a way to handle those kinds of data then?

I believe you’re wrong on this @bwe - germ covers content types and datasources too, at least for diffing so you know what changes to make where and ensure consistency.

@selbekk - please read the GERM process carefully to understand all the details - there are also relevant tools mentioned.

@rfo is the guru on GERM - he might have something to add here?

Germ process talks a bit about the best way to handle contenttypes and datasources too. I think it mentions a way to extract contenttypes and datasources with the cms-shell command “db extract” which extract datasources from database to XML file." and diffing this extract by using the method described in the labs article “How to diff various Enonic CMS installations”. But mostly the germ process describes how to best work with content to get around the restrictions in the cms for moving content from between installations, the recommended way is to build stuff in production and copying the database to test servers when needed. Also I have created a ccontent-plugin for copying/migrating content between environments, but it requires some setup to work.

To help out with the germ process, I have created a not-official (but successfully used by several customers) germ-plugin that automatically initiates a git repo in the the Enonic resources (or plugins) folder. It fetches static content from a git repository into the resources/plugins folder on the server. It also features a enonic scheduler to fetch code from git with a cron expression, handy for test server that should always be updated with latest commits. It does not require much setup, it needs to be packaged, deployed on server and accessed on url /admin/site/[n]/germ on your Enonic Installation.

Here are some screenshots to give some indication of how it works:




2 Likes