In explaining what Magick does in SharePoint, I’ve previously briefly described how awesome Magick the Framework is and what SharePoint problems Magick solves.
However, that’s just the start of what Magick does.
In this article, I’ll explain how Magick allows you to implement agile approaches to SharePoint development by supporting continuous upgrades and evolutions of your SharePoint solutions.
Oh, and if I haven’t mentioned it already or you haven’t guessed: Magick works across all SharePoint versions, at least from SharePoint 2007 and onwards.
What are Continuous Upgrades?
In Agile development, a key principle is that you build and deploy functionality very rapidly. In fact, in many cases, you create functionality every week of a long project, and users get access to that functionality immediately.
This approach is a win-win for both the developers and the users. Users get to see rapid progress and get access to important functionality as soon as it is ready, rather than having to wait for a long time until an entire software development project is complete.
This also allows them to give feedback during development, for example to suggest further improvements, new features, or changes to features they don’t like.
For developers, the continuous feedback and rapid deployment means they can find issues sooner and can vastly improve the solution. It also means that the development sprints, as these short development cycles are often called, are done sooner so one gets more variety in development and see the results of ones work more quickly.
However, in SharePoint, this approach is often very difficult due to the somewhat static nature of how SharePoint works. If you recall from the previous article, many SharePoint components cannot be changed ever after they have been deployed once. How can you then make continuous improvements and deploy updates on a regular basis?
In a Word: Magick!
In Magick, we not only support the static nature of SharePoint solutions, we encourage it. In fact, in Magick, we build a solution once and we never touch it again, at least in a perfect world.
That may sound strange for a framework that claims to be agile and support rapid changes first and foremost. However, it is really quite simple.
Magick wants you to think about changes in your solutions, and not how something came to be. In other words, we look at how we need to move from point A to point B, not how we got to point A in the first place.
In the traditional approaches to SharePoint solutions, you often start out by deploying a solution that does something. This is what gets you to point A. Traditionally, when you need point A to change, many developers will look to change the solution that got us there. In technical terms, they modify the solution file and redeploy the solution.
This is problematic from a number of perspectives.
First, many components cannot change after they have been deployed. This is due in part to Microsoft policies, but more fundamentally, due to the way SharePoint solutions work. Remember that SharePoint solutions are recipes for how to build something, and changing the recipe does not change the already produced goods.
In Magick, however, we never change a solution after it has been deployed, with the exception being .NET code which can change if required, but also should be left as much alone as possible.
Instead, we seek to create solutions that look at the current state of affairs and what is required to move to where we want to be.
Forgive my slight technical departure here, but let’s look at a fairly simple example.
You have deployed a great new solution for project management which includes a great new list of project tasks. After a couple of weeks, users come back to you and say that they really like it, but would like different options for sorting and filtering the list.
In traditional SharePoint development, you’d simply go in and modify the original solution to support the new requirement. This, of course, breaks Microsoft’s policies on never changing any declarative components, but more importantly doesn’t always work. Users may already have modified the list, and if you redeploy those lists with different functionality, you may break what the users have worked hard to accomplish.
In Magick, on the other hand, you would instead deploy a new solution that will modify the list and add whatever functionality the users requested. Depending on what change you want to make and the toolset you have, this allows you to check whether the new change will actually make sense in a particular situation.
Of course, doing more advanced detection requires .NET code, but if you can use that, you can just check whether the current view is unchanged from when you originally deployed it, and only change that view if the users themselves have not made the changes. Otherwise, you could create a new view for them, or simply not make the changes at all.
Are these types of changes supported? Yes, very much so. In fact, you are really just automating the tasks that the users would do themselves through the web interface, including the decisions made to determine if you want to perform those tasks.
If you are allergic to .NET code, fine, you can still make certain changes, but mainly to add new components rather than change existing ones. Like I’ve said many times, if you really want to get stuff done, use third tier development and .NET code 🙂
The keen observer will at this point ask two very important questions.
First, if you build new solutions for every change, wouldn’t you end up with dozens of solution files rather than a single, easy to manage WSP?
Second, if you create new features all the time, won’t you create complexity in deploying new sites or upgrade existing ones? You’ll end up with tons of features that you need to activate in the right order!
These questions are exactly what Magick handles for you. In fact, it doesn’t handle anything else.
For the first question, remember that in Magick, we never touch a solution file ever again after it has been deployed. A lot of the reason why administrators see WSP files as problematic is that they need continuous management. In Magick, they are deployed once and then forgotten. There are no upgrades, there are no changes, so management of multiple files is actually easier than managing just one file.
For the second question, I’ll show you later how Magick handles upgrades, but suffice to say, users rarely, if ever, see or need to see any of the features you deploy. Magick handles the upgrades for you, including making sure everything happens in the correct order, for the sites that need to be upgraded only, and within the scope required.
I’ll detail that in a future article, though, and then I’ll show you all the code, the conventions, and the Magick behind it all 🙂