Agile SharePoint Development – Using Visual Studio Online

Hi There Folks

Continuing on the theme of Agile development, specifically setting up SharePoint 2016 using Agile methodologies I thought it was time to talk about some of the tools I use.

First out of the gate is Visual Studio Online.

Agile SharePoint Developement – Building a Farm

Hi There

So the first case study in Agile SharePoint Development will be, to celebrate the release of SharePoint 2016:

Build a SharePoint 2016 Farm with Multiple Tenancies and ADFS

Agile SharePoint Development – SharePoint

Finally we get to SharePoint having covered Agile SharePoint Development – Agile and Agile SharePoint Development – Development.

So how does agile development in SharePoint differ from that in other languages and environments?

It doesn’t because, and here lets refer back to the Agile Manifesto once more, Agile is not about the how, what, where, when or who its about the why.  Use whatever techniques you like Sprints, SCRUM, pair programming, test driven design, continuous integration or deployment, the list goes on just know why you are using and be able to explain why you chose the techniques you did and be ready to change them if they are no longer appropriate.

Having said that experience shows that some techniques work much better than others and some techniques for SharePoint development lend themselves to Agile working whilst some don’t.

A Place to Stand

One thing is absolutely vital though you must have somewhere to work, and that needs a copy of SharePoint that will not impact end users.  You don’t expect a car mechanic to put snow chains on your tires whilst you are driving the car.

So your developers need a place to work where it won’t affect other people.  There are multiple ways of doing this and some are more applicable than others generally but we are being agile so be prepared to evaluate and choose what is right for you, now.

• A dedicated SharePoint Farm or Tenancy, the ‘ideal’ solution but potentially expensive in license and ownership costs.
• A dedicated Web Application, one of the few good reasons for a Web Application and On Premises only.
• A dedicated Site Collection, very often the pragmatic solution but some things like Managed Metadata span all Site Collections.
• A dedicated Site, not to be dismissed out of hand especially when doing small ‘tactical’ developments as you get a ‘real’ environment.

Some Decent Tools

If the work is serious you don’t do it in your front drive but you take it to a repair shop where they have the serious equipment, car hoists, engine block and tackle, etc.  I can write you a custom SharePoint Add In with nothing but notepad; the command line c# compiler and a Diamond Directive File command line packager but it will take a long time compared to working in Visual Studio.

As opposed to environments there really is only a single sensible choice for your main development tool almost irrespective of what you are developing and that is Visual Studio but there are some extras that can greatly enhance your developers’ productivity and, Agile again, there are some styles of development where other tools can be a better choice (JavaScript injection to implement Angular drawing from REST springs to mind).

• Visual Studio Enterprise Edition, although pretty much any version will do.
• ReSharper
• XUnit

Known Techniques

You don’t need to reinvent the wheel every time so use tried and tested techniques, there are some that work very well with Agile and SharePoint and others that don’t.

• Sprints, almost a given, they focus the mind so well and keep things manageable.
• SCRUMs, not absolutely necessary and often hard to get business buy in but if you can do them they work very well.
• Pair Programming, definitely worth it, the quality increase is startling.
• Unit Testing, works well but beware mocking SharePoint objects for that way madness lies.
• Test Driven Design, less suitable due to the problems of mocking SharePoint but worth considering for small tasks.
• Continuous Integration, if you have multiple developers its a must, if you are on your own, it’s still a must.
• Continuous Deployment, this is hard especially if you are updating multiple sites as the time to do it for a reasonable sized farm can easily run into the hours, however ‘automated’ or ‘scripted’ deployment a pre-requisite for this is an absolute must.
• Kanban Board, if you are doing Business as Usual or lots of small enhancements this is fantastic in terms of keeping it all flowing.

So that’s a quick round up, next is a set of case studies showing how we do this in practice.

Cheers

Sebastian

Using Themed StyleSheets in your SharePoint Web Parts

Hi Folks

A simple little trick here.  We have developed a nice tabbing web part (which is NOT a jQuery wrapper which shows and hides but a ‘proper’ we only load what you need tabbing system) and as part of it we wanted to use the Search Navigation Web Parts theming.

We did this for consistency so that out of the box the experience with our web part is identical to the only other tabbed interface in SharePoint.

We also wanted to respect any theming that was in place rather than force our own onto the part.

Now its very easy to reference a SharePoint themed style sheet in a web part the trick is simply in OnLoad to use the CssRegistration class as follows:

protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
CssRegistration.Register(“Themable/searchv15.css”);
}

Now the style sheet will be loaded and you can use its styles.  In addition if you are using theming the themed version will be loaded for you so your colour and font choices are respected and finally if anything else has requested the same style sheet it will only be loaded once.

Cheers

Sebastian