Post-Live Deployments and Releases How-to

[MihaXO]

Hi guys, 

I am the Project Manager for a project we are doing with dotcms. I hope you guys can help me.

We are planning to do an initial release of the revamped website, and to add more features after that. We have allowed CMS users, with different access levels to publish content on the live website, and we will develop the next features on a separate server first. I am not sure how the deployment should happen after we have released the website and the content will be changed, considering that some of the features we will add, will require database changes as well. 

Can someone help me understand what are the best practices in this situation? Any advice or links appreciated. 

Thank you.

[Nathan Keiter]

I would consider five main factors when moving features from a dev server to a live server:

 

Transition Smoothness/Preparedness, Visibility, Dependencies, Downtime, and User Shepherding

 

Transition Smoothness/Preparedness

-       Pre-load as many parts as possible before going live.

-       This includes, but is not limited to Content Types, Content, VTL files, CSS files, JS files, and OSGI plugins.

-       Have as many components in place as possible well in advance of going live.

-       It doesn’t matter if they function or not (due to missing dependencies), so long as they don’t interfere with current operations.

 

Visibility

-       Keep in mind that you can hide large portions of the site via permissions until they are ready.

-       You can even (and should) lock features based on permissions. (ViewTools, RESTful services, Spring controllers, Servlets, etc.)

-       Only make the feature visible to a small test group until you are sure it is functional.

-       You can also temporarily “lock out” people from making changes for a short time if needed via permissions.

 

Dependencies

-       Keep in mind what parts just won’t work or cannot work without other pieces being in place.

-       At go live time, add features in dependency order, starting with the foundational pieces and work up from there.

 

Downtime

-       If downtime is unavoidable due to static plugin changes or invasive database update scripts, plan ahead.

-       Backup, backup, backup! Backup your site & database.

-       Automate, automate, automate!  Scripting/programming is your friend, avoid redundant manual tasks.

-       Have a recovery strategy.

-       Know exactly when and what you need to do.

-       All other possible components and dependencies should be in place before downtime.

-       If possible practice the steps on another server to gauge the timeframe needed and discover any issues that might occur.

 

User Shepherding

-       If you are changing the user experience, keep training in mind.

-       Have all training programs and materials ready to go BEFORE go live.

-       Train the trainers first.

-       Gauge user shock level/concerns/responses in a small focus group. – Be sure to address those!

-       Have a support team in place to help users find their cheese again.

-       Document, document, document!  If you get lost, everyone else will too!

 

Nathan I. Keiter | Lead Network Applications Programmer | Benefits Advisory Council Member | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993

https://www.gettysburg.edu

--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To post to this group, send email to dot...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/2a6130a2-2789-4dd1-b0c4-af2cca0ecd7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Falzone]

Might or might not help ...  This is how we do.  Not going to claim any sort of best practice here, but it works well for us.  

Ww use push publishing for content and use the REST Content API via Jenkins to deploy VTL and Plugin Changes.  We never modify dotCMS at a database level, this is unadvised and in my experience there is always a better solution.

Our environments look like:

Development (App/DB) -> Staging/Authoring (App/DB) -> Production (App1/DB1 + App2/DB2)

Content release happens from staging.  All content changes are done on the staging server.  Both developer changes and content editors.  For development purposes we push the content change from Staging to Development.  For releases content is pushed from Staging to Both Production servers.  We do not use clustering, both production servers are kept in sync using push publishing.

Related Doc:  https://dotcms.com/docs/latest/push-publishing 

VTL (including CSS/JS/Other Assets) releases happen from github.  We have a branch that tracks what is on Staging.  Development is done by branching a feature off of that branch.  During development, the developers use WebDav to upload their changes to the Development environment.  Any new files are push published to Staging and then to Production immediately to maintain Identifier Consistency across all of the environments.  After development is complete, the feature branch is merged into the staging branch on github.  Jenkins monitors our github staging branch and we use a script to publish the changes over the REST Content API. At this point the work is checked by our QA team before being released.  When we are ready for release, we make a release branch from master and merge the changes currently in the staging branch into it. Once the changes are reviewed we merge the release branch back into the master branch, which triggers Jenkins to deploy the changes over the REST Content API to both production servers.

Related Doc:  https://dotcms.com/docs/latest/content-api 

Plugin releases are similar to VTLs.  Tracked in github, released by Jenkins.  The only difference is that the OSGI Bundle Jars are upload and deployed over SSH from the Jenkins server to the dotCMS app server.

Last year at the conference I shared some details about our process.  The slide-deck and code examples might be helpful for you:

https://github.com/aquent/dotcms-bootcamp2016 

I don't know if that helps.  It's pretty tailored to the way we do work.  One of the core things we do is, work has to be done in a way that nothing that gets into the staging branch that cannot be released on to production, at least from the developer's perspective.  This allows us a more agile release cadence.  We at least plan on releasing once per week, but often have single feature releases throughout the week as they are done.

When we have major breaking work being done a site that requires breaking-changes, this is normally done in a copy of the host on each environment.  And release is then done by switching the hostnames in dotCMS.  But this only happens on a two to three year cadence for us.  We try to make incremental improvements more than wide-sweeping changes that require a process like this.

Some of the challenges with this approach are ...

Occasionally work gets held up.  Whether is waiting for a stakeholder to approve, or whatever.  This can be disruptive to our process if the changes for this feature are already in the staging branch.  it means we either have to roll those changes out of staging to do a release or we need to do releases by cherry-picking what we want.

Structure-Level changes can be difficult and need to be done in a way that they can be released immediately without breaking anything.  The reason for this is if any content is pushed from staging for that structure it wipes out the Structure changes on dev.

There is no way with this approach to silo a release for testing. We are working on this.

There is no way for developers to work on assets individually.  So if I need to make changes to the same file as another dev and upload that to dev and he uploads the same file to dev we step on each others' toes.  We are hoping to leverage docker or something similar to spin up dev environment for each developer locally to combat this issue.

Hope that helps!

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/b1581130a1c248ee8081987817ef4e6f%40exch13c.ms.gettysburg.edu.