Content management options in CI/CD development

Vote:
 

We are starting a project where EPI CMS 7.5+ will be used, we usually do our agile development in a Continuous Integration / Continuous Deployment process which supports both full Content Overwrite and Content Delta/Migration when end users have started entering Content or production site is in use.

 

I have read and searched about ways to implement Content delta/migrations with EPI CMS and have not found built-in functionality or third-party tools that provide such functionality, if there are such solutions please send us relevant information.

 

I have tested DataExporter/DataImporter classes which could be a starting point for a custom-developed alternative, but before we go further we would like to validate our approach to ensure we are on the right track and have the right comprehension.

 

By the way: We use Source control servers, build servers and deployment servers/orchestrators and have multiple environments after developers machines for different purposes (INT, QA, UAT, STG, PROD), but since this I not part of the aspects we want to validate they are omitted from the following discussion…

 

So, our main concern is how to manage and propagate Content from an environment to the next in two scenarios, the first is when there is no Content entered by the End User, the second is when there is content entered in Production by End Users and new features are developed (hence new releases) at the same time.  Also, Content Types will be managed by code (and we assume o overrides are done in admin UI).

 

So here is what we understand and what we plan to do…

 

Approach for Content propagation across environments when no content entered from Production

Once a release is ready, we would proceed this way:

1-      Developers enter basic / required Content for a functional site [1]

2-       Backup DEV DB and restore as STG DB[2]

3-      Copy other artifacts (code/configs/content types/etc.) to STG

4-      Our integrator enter additional Content for demo and site features viability (ex: Landing pages, couple of news, etc.) [3]

5-      Validation of correctness on STG environment

6-       Backup STG DB and restore as PROD DB[4]

7-       Copy other artifacts (code/configs/content types/etc.) to PROD

8-      Validation of correctness on PROD

Approach for Content propagation across environments when content is entered from Production that cannot be lost

 

1-      Content used in DEV and STG are a restore from a recent backup of PROD (but not necessarily very fresh, no Content Types have changed)

2-       Backup DEV DB and restore as STG DB [1]

3-       Copy other artifacts (code/configs/content types/etc.) to STG

4-      Content freeze in Production starts

5-      Export PROD Content via EPI admin UI [2]

6-      Import Content exported from PROD in STG [3]

7-      Validation of correctness on STG environment

8-       Use DEV/STG Backup and restore as PROD DB [4]

9-       Copy other artifacts (code/configs/content types/etc.) to PROD

10-   Validation of correctness on PROD environment

11-   Content freeze in Production ends

 

Approach for Content propagation across environments when content is entered from Production that cannot be lost and additional Content need to be entered by integrators

1-      Content used in DEV is a restore from a recent backup of PROD (but not necessarily very fresh, no Content Types have changed)

2-       Backup DEV DB and restore as STG DB[1]

3-       Copy other artifacts (code/configs/content types/etc.) to STG

4-      Content freeze in Production starts

5-      Export PROD Content via EPI admin UI [2]

6-      Import Content exported from PROD in STG [3]

7-      Our integrator enter additional Content for demo and site features viability (ex: Landing pages, couple of news, etc.) [4]

8-      Validation of correctness on STG environment

9-       Backup STG DB and restore as PROD DB [5]

10-   Copy other artifacts (code/configs/content types/etc.) to PROD

11-   Validation of correctness on PROD environment

12-   Content freeze in Production ends

#113547
Nov 24, 2014 15:11
Vote:
 

Sorry images did not follow...

Approach for Content propagation across environments when no content entered from Production

Approach for Content propagation across environments when no content entered from Production

Approach for Content propagation across environments when content is entered from Production that cannot be lost

Approach for Content propagation across environments when content is entered from Production that cannot be lost

Approach for Content propagation across environments when content is entered from Production that cannot be lost and additional Content need to be entered by integrators

Approach for Content propagation across environments when content is entered from Production that cannot be lost and additional Content need to be entered by integrators

#113548
Edited, Nov 24, 2014 15:18
Vote:
 

This is going to introduce a lot of complex scenarios like you have to do code freezes and so on. The normal way of using EPiServer CMS is to always produce production content in the production environment, when a new release should be tested in stage do a full database back-up from production environment and add the content manually to test it. When the developers want to update their own databases with newer content take a full back-up from the stage environment.

So if the functionality build by the developers is restricted and easy for the editor to use there will be easy to set up a whole new website in the production server directly, this will minimize the risk of getting test data in the production environment.

So for normal development I strongly recommend to following the principles:

1)      Always create content for public use in the production environment.

2)      Utilize EPiServers build in functionality to restrict content to be used in wrong places; this will also help the editor to always create a full working site.

3)      Develop with fallback – this means that everything that the editors are able to with their input fields should generate acceptable HTML, and all content structures (defined by point 2) should be acceptable and generate correct HTML.

4)      When fresh content is needed on the developing/test/stage machines take a database backup from the production environment.

#114155
Dec 05, 2014 10:34
Vote:
 

Hi . How did you handle the content migration?

#186126
Dec 12, 2017 23:24