CODEWITHSUNDEEP
gitsitecorebitbucketatlassian-sourcetreegit-flow
yofi
yofi

Reputation: 33

Best Git workflow for Sitecore

Sitecore is a content management system that my company uses. We have three environments: Dev, Stage, and prod. we are using BitBucket with SourceTree (using gitflow workflow) for most of our development work.

We are running into issues applying the same flow for Sitecore, because there are two different types of people who make changes to the site.

One is the developers who create a feature branch to work on some features and the integrate in the development branch. The others are the power users who work on the staging site that create dynamic content. The dynamic content is everywhere, so there is no way to isolate it.

So, during deployment we have to go through a painful process of merging the changes the developers made with the changes in stage to get it ready for deployment. Is there any git workflow out there that can work for this type of scenario? Thanks!

Upvotes: 1

Views: 197

Answers (1)

harmonica141
harmonica141

Reputation: 1469

This is not a git but an organizational problem. You cannot have developers work on production (i.e. with dynamic live data) nor produce on a development site. You must be wasting incredible amounts of time resolving merge conflicts.

To solve this, separate the two fields - this can be achieved by a time constraint applied on top of gitflow (which seems a nice choice for a git pattern). Your conservative way to a release then will look something like this:

1) Manager grabs a calender and defines dates: feature freeze, dev freeze, content freeze, release.

2) Devs add features up until feature freeze, then do their integration testing and finish their work on the version until dev freeze. After that you can be sure the version will not change anymore developmentwise.

3) Then come the content guys and do their magic until content freeze. Usually this should not interfere with the functionality of a correctly developed and tested cms.

4) Do testing and editing.

5) Release.

But, better: For something with such an agile potential like a cms this is a quite lengthy process. If you want to go for a bit more continuous integration, do not use gitflow, do not use discrete releases: Branch from production, develop a single feature, test, merge, bugfix; same for content. Time frame here: hours to a few days max, the shorter the better. Merge conflict potential will be minimal due to the tight time frame for changes in master vs the large difference between two discrete releases (google agile development, continuous integration).

A word on content separation: When you say you are having a hard time merging functionality to content there is another problem here: content should not interfere with programmed functionality, especially in a content management system. If it does, you either need to separate devs and users more or - much better way - make them talk more to each other. Define processes that integrate both parties and make it organizationally impossible to make conflicting creations by working together. Have them sit together if possible. Change seats depending on who is working on closely related topics. At a minimum have regular (daily) team meetings and create the option to talk between those. Get your time frames tight (talking about really small bits of work between milestones, not more pressure for the entire thing...).

Upvotes: 1

Related Questions