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.
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.