I know this may well be one of my controversial views, but… One of my pet hates of the modern era of Sitecore development is the insistence that front end developers work in the same place / same way as back end developers. I have been involved in many projects (100s for sure), small and large and on differing technologies. Whilst this approach can work ok on a simple MVC application, I think it is pretty poor on the Sitecore platform and here is why:
Front End Developers in Visual Studio
Many times lauded as the holy grail, development teams seem to love the idea that front end developers skin the site from within the same toolset as the back end folk. This for me is inherently flawed for many reasons – noteably:
Front end developers are forced to use tools that are best of breed for .Net developers. I have yet to see any front end developers on the 25 odd Sitecore builds I have currently been involved CHOOSE Visual Studio as their go to product for their daily life
Front end developers for many reasons – notably testing, choose to run on different hardware to back end developers. Quite often a Mac. This for front end developers makes inherent sense as testing Safari, Chrome for mac, Internet Explorer, Edge, Firefox etc is far easier done from a Mac running a VM than attempting to use a buggy Hackintosh build the other way around. I know there are services now that help this.
Back end developers would most likely feel aggrieved if they were told they were going to work on Linux and MonoDevelop studio when Visual Studio just does things that much more easily (don’t get me wrong – I am a penguin at heart, but I would definitely switch to java in that instance).
Sitecore Developer Support
So – now they have the front end developers subdued and forced into working in an unnatural way. Lets add the sheer bulk of Sitecore.
Senior front end guys can easily outpace the back end teams in terms of rate of delivery of assets, they are used to working in a hyper fast work cycle where html is generated quickly, and modifications take effect quicker than they can cmd + tab. Instead, several times a day they now have to fight Sitecore (remember they are not even .net developers), running builds & synchronisation processes to get the latest renderings / content that the back end developers have generated.
Once they have achieved this, then processes are usually developed by the back end team to force the refresh of assets without a rebuild, these usually conflict with the publish model from visual studi, leaving a messy resultant build.
At least once or twice a week, the front end developers run into some kind of sync / build / deployment issue. This of course means that back end development instantly becomes third line support for the front end team, or… at the very least.. Every Scrummaster in the universe is running around with their pants on fire screaming ‘blocker’.
Continuous Delivery Builds
Front end developers can and often will commit on a much more regular cycle than us in back end. They can fix bugs in minutes, where ours can take quarter of a day or more. In a perfect world, these commits trigger at least an integration build. Not an issue per say, as the integration builds are not damaging to anyone. However, a front end development cycle will likely not include testing of back end functionality, so, when put in the context of triggering a qa build (and potential live promotion that follows) there is a chance that changes that are not correct for the business could sneak through. Granted, we should all be testing everything all of the time, but these things can and do happen.
As spoken of above, the ability for a front end development team to run through skins / bugs is far quicker than that of back end teams. From this position, why do we hamstring them by waiting on the back end team being ‘ready to release’. Why wait for a week to change the image quality of a banner and a critical fix to an single page application section that could be costing the wider business $1000’s when it could be promoted independently of the site. Front end development can usually fix their mistakes quicker by going forwards than reverting. That comes out of the box in their inherent speed.
For those of you that have in your career worked on a server side scripting language such as classic asp / php. We faced the same thing, we could often fix our problems at an incredible pace since there was no considerations for content editors, build times, content synchronisation etc.
This in many respects (and I have seen massive industry players fall foul of this) is quite often driven by definitions in their project management process. The notion that front end developers are only delivering business value if it is part of a completed functional area inside Sitecore.
I think this flies in the face of one of the cornerstones of what it is to be agile as a business. Front end developers ENABLE back end developers to complete their work, in addition, they can provide functionality immediately to customers that either helps them complete simple journeys or unblocks them from aspects of their journey due to a bug. Embracing the agile principle of delivering value early to a customer for me, would surely mean that we are hampering our own agility by forcing front end development to work in this hamstrung fashion.
It is worth noting that Kanban better supports the notion of cadences in the lifecycle, one of the reasons I prefer it as an methodology.
So – how else might you control this? For me, I like this principle, but I am sure given the same time and effort spent on bodging processes into Visual Studio, better ones could be found.
Simply give the front end guys their own repository. The back end developers pull from this repository and hotline to the assets that are generated by their gulp / grunt builds. In addition to this, ensure that the hot linking and front end development mechanisms have the ability to support versions, simple folder structures will often suffice, so /v1, /v1.1 etc
So when linking to the js file, the resultant source would be http://assets.mysite.local/v1.3/scripts/myscript.js. This has the potential for performance benefits too, since the front end assets could be served from a completely separate service if you so desired as well as the requests / domain limitations of some browsers (though I think this is likely moot in the modern era)
There could also be consideration given to allowing this to be changed for production to allow the moving forward of builds
I will grant you, that one of the key benefits of having the whole thing inside Visual Studio is that version history. Realistically though, with correct tagging in the front end repo and just a little bit of management, the same could be achieved with a wiki page. I think all of the reasons listed above are enough for me to consider this a small price to pay.