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

Avoiding SharePoint Magic Numbers in Unit Testing

Unit testing really is good. No surprise to those who do it but recently we had a test go red when changing how we configure Enhanced Records Manager, see
Appropriate use of AppInstalled for a Provider Hosted SharePoint App for more details.

Not a problem we have broken something lets fix it.

It turns out that every properties metadata was being added twice to our configuration database.  Simple.  We had inadvertently called the ImportProperties method twice.  So all we have to do is remove the wrong call and we are away.  Hold on isn’t import properties supposed to update if the same property is imported twice not add.  Lets dig further.

So when we unit test we don’t use SharePoint, its too ‘heavy’, but we have abstracted it in the design to an Interface called the RecordRepository Interface which has ‘generic’ methods, such as GetProperties which returns all the properties the Records Management system.  This gives us two great benefits:

1. We can replace it for unit testing by a lightweight RecordsRepository currently a pure in memory one.
2. We can use Records Repositories other than SharePoint by ‘merely’ replacing the Records Repository as it only deals with access, not logic.

The ImportProperties unit tests weren’t failing so the actual logic was okay, well we all know GIGO (Garbage In, Garbage Out) so if the output is wrong but the logic is right it must be the input.  And Lo and behold so it was.  Our Unit test Records Repository generates a defined set of properties using Guids as their unique identifiers.  Good.  Problem was they were generated each time the GetProperties method was called so if you called it twice you get two sets of properties identical in all but identifier.

A long preamble but it got me thinking.  Why hadn’t we just used the known identifiers for the SharePoint built in fields?  Title is always {fa564e0f-0c70-4ab9-b863-0177e6ddd247}.  We didn’t so why?  Ah yes go back to point 2 the design of ERM is that it is repository agnostic.  If we had just used the ‘magic’ value when we changed the actual Records Repository we could have been in the position where our unit tests passed fine but it failed in practice because we had been lazy and also used the magic value somewhere in the business logic.

So we generated Guids just for our Unit test Records Repository as fixed Guids and that sorted that.

Cheers

Sebastian

SharePoint 2013 Administration Tools

One of the interesting side effects of the Infrastructure as a Service (IaaS) that seems to be getting more popular is that as well as supplying software we are now also taking on more of the ‘Infrastructure’ role. This seems to be because the client feels that “we don’t do IT now we outsource that” whilst the Service Providers have a very “We run the tin, the network and the OS but nothing else” attitude. This leaves the poor old application with no friends. So as no-one else is doing it we have started taking on this responsibility for hosted solutions.

I don’t think this state of affairs will last. Our Office 365 products are essentially maintenance free and as Software as a Service (SaaS) becomes more prevalent this responsibility will move back to the hosting company but for now its slipped between the cracks.

Ultimately when we move to Transactions as a Service (TaaS) it will disappear completely and we’ll all be very, very glad.

In the mean time we find ourselves configuring and supported hosted SharePoint 2013 solutions, not a problem the folks here probably know more about how to do this than most IT departments.

What it does mean is that we have been thinking about what tools a SharePoint Administrator must have on their desktop (or pinned to their task bar).

1. Internet Explorer, how else will you be able to test what you have done.
2. SharePoint 2013 Central Admin, still the first port of call when wondering how things have been configured.
3. SharePoint 2013 Management Shell, still really useful for quick ad-hoc scripts.
4. Internet Information Services (IIS) Manager, for checking security certificates, .config files, web application pools.
5. SharePoint 2013 Manager, gives you the ability to drill down and investigate SharePoint via its API, incredibly useful for working out why things aren’t as you expect, i.e. showing you the Event Receivers on a list.  Pity its icon is very similar to SharePoint 2013 Central Admin.  (http://spm.codeplex.com/).
6. ULS Viewer, gives you the ability to view and filter the SharePoint logs.  With this you can actually find the errors, the alternative, looking through the many, many .log files with a text editor is very unpalatable.  You could do it but then again  you could always poke out your eyes with a stick, a blunt stick, your choice. (http://archive.msdn.microsoft.com/ULSViewer).

Cheers

Sebastian