version control scripts in document libraries to TFS

Question

How can I version control in Microsoft cloud TFS the html and js files which are stored in document libraries? I have these kind of questions: How could I

• "publish new versions of the solution" (what would be an easy way; should we for example create a PowerShell script which will deploy the files to the correct folder structure, and update one file which contains the version numbers?
• See the current version number (if we, for example, branch new versions every now and then - where to store the currently "deployed" version number of all of our files if we deploy them all at once)
• What would be a nice way to arrange the html, js, css files in document libraries? (and should we replicate the structure in our VS solution for easy updating of them during versioning)?

A simple example might be where the solution spans a couple of subsites inside one single site collection. Subsites could contain CEWPs in web part pages in document libraries. The CEWPs point to html files which reference one js and one css file per CEWP. Files need to be kept in Microsoft cloud visual studio for a global development team, and deployed to on-premises SharePoint every now and then.

For example

• SiteCollection/MySolutionFiles/MyComponent/my-component.aspx
• SiteCollection/MySolutionFiles/MyComponent/my-component.html
• SiteCollection/MySolutionFiles/MyComponent/my-component.js
• SiteCollection/MySolutionFiles/MyComponent/my-component.css
• SiteCollection/Lists/MySolutionVersions/

and the same structure in visual studio (starting from MyComponent) storing other files than the aspx (web part page with CEWP). PowerShell would then copy-paste all the files to the SharePoint site collection, overwriting the existing files and saving a new row to the versions list (which might contain VersionNumber, Description)

Answer 1

Enable major and minor versioning in the document library and set up required check out to edit the files. This can be found in the Versioning Settings of the Document Library settings.

This will give you the ability to version control the assests, see who has changed them, do content approvals if required, and rollback if necessary.

The version number field can be added to the default list view.

Answer 2

Since you are already talking about using Visual Studio I would suggest that you create the SharePoint Solution package (.wsp) and features and use that to deploy the solution to the server. I have used the build service on the cloud TFS to build SharePoint solution packages (.wsp) as well. That should be able to cover what you need to get deployed and since you have an on-prem install you shouldn't be restricted to sandbox solutions.

I would suggest that you make the structure in the Visual Studio project match how they are deployed so that references to .js files from the .html file will resolve and give you design time assistance.

You will be able to use TFS to handle all of the branching. If you use the build service you can also keep the version of the build that you have deployed to production and even update the comments on the label in TFS.

I know it is possible to copy the files to the server as you describe with PowerShell but you may run into a case where someone is changing the files on the SharePoint server directly and not updating TFS and then a future deployment will remove that change.