0

I'm looking for a best practice methodology for version control for multiple front-end developers working together on CMS based websites.

So we have several CMS based websites in active development. If you are curious, the CMS is DNN. On our test server we have front-end developers working with CSS, JS, and also adding content to pages which is of course stored on the database. We also have module developers who have local copies of the source AND database where they develop and promote to the test server. And we have a TFS server where the module developers can house their repos for version control.

My question is, how do I get front-end developers on version control? They can't have local versions of the database because all of their content (database) updates would be constantly out of sync with the test server. It's unrealistic for them to build change scripts for their content/page updates for the database (not to mention it is a different skillset and defeats the purpose of the usability of the CMS). They can't all host local copies of the files and then connect to a shared remote DB because the application uses memory cache..which would be.. you guessed it... out of sync.

I feel like I'm missing something here because other organizations must be accomplishing this somehow. We absolutely need version control on our JS/CSS resources.

Thanks.

Rubén
  • 34,714
  • 9
  • 70
  • 166
Russell
  • 189
  • 3
  • 12

1 Answers1

2

You effectively have two sets work work that should be treated separately.

The first is your version of DNN and the customisations that you make. These should be stored in version control and you should create a deployment pipeline to ship the bits from build to servers.

The second is your in application customizations that are done with point'n'click. These are not versionable in the traditional sense and should be considered instance specific. You could, and probably should, script out all of the customisations of data and version that. So you would have a folder for each instance that you ship with the state if the data at the time you shipped.

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69
  • Thank you, I think I am grasping what you are saying.. Are the CSS and JS files for each instance of DNN part of the non-versionable portion of work? I ask because as our designers/front-end developers build out pages, they are constantly modifying these files... it just seems that it would make sense to version control them. EDIT: I also just had a though, are you perhaps suggesting that the front-end developers do not make changes to these files? I suppose they could place inline scripts/styles on pages as they go. – Russell Feb 13 '15 at 15:27
  • 1
    No, DNN support theming and components/plugins. All 'customer' specific customizations should be either a component or a theme. That way all of your customers code/customisations can coexist in the same branch. – MrHinsh - Martin Hinshelwood Feb 13 '15 at 19:00
  • 1
    It just clicked. I was so focused on the how, I wasn't thinking about the why. It's our approach that is flawed. Thank you for re-clarifying :) I knew I was missing something. – Russell Feb 13 '15 at 20:36
  • That my full time job – MrHinsh - Martin Hinshelwood Feb 14 '15 at 10:33