Development Machines

There are a couple of different schools of thought here.  Some people prefer running a virtual dev box on there local machine whereas others prefer running on physical hardware or using remote desktop into a development farm. Personally I prefer using server hosted virtual machines. There’s a lot to be said about how much easier it is to clean up your dev boxes after a long running project and the individual developer doesn’t have a powerhouse of a machine. Another real bonus here is that you can setup one development machine as a master and create all of your other dev boxes from it so it’s not only quicker to spin up but you can ensure that all of your developers are using the same tools which is really pretty nice. 

On the note of tools there are some really nice ones out there.  I won’t get into a knockdown drag-out  fight over which tools are best for developing (at least not at this very moment). I’ve used some of the community tools like WSP Builder and I’ve used several versions of VSE.  I will say that VSeWSS 1.3 is much better than some previous versions and that if you haven’t tried it you probably should. The real important thing to understand here is that it’s not about which tool you use, it’s about using the same tool every time.

Source Control, build machines, and a testing plan

Ok all of the concepts in this section are miles deep and each deserve more than just a mention but those are posts for another day.  Instead I’m just going to go into what my plan is, proceed at your own caution.

My Plan:

Setup Developer VMs and connect them to TFS.

Matching the production farm doesn’t make all the difference in the world here. Standalone machines will work fine.  Just make sure that some important things match. If your production farm is x64 that your developer machines are x64. If your production farm is Server 2008 r2 your developer machines are Server 2008 r2.

Create a SharePoint Dev farm to be build machine one.

This is where you have to match your production farm as near as possible.  That means you need to match the production topology, service accounts used (if you can), and even SQL configuration.  If anything is different on your production farm that will be the thing that brings down your farm and starts the zombie apocalypse.  Also this is where you want your continuous integration build (build on check-in) to happen. That’s going to be what most clearly separates this build server from any others.

Create a testing farm to be build machine two.

Just like the last time if you don’t match the production farm here you’re going to be the one responsible for the zombie apocalypse… do you really want to be that person? The builds on this machine should only be kicked off when code has passed review and is ready to really be tested. You know, by real testers.

Ok, so here’s what that looks like:

Developers –> TFS –>  Dev Farm –> Test Farm –> Production

So what’s a dev to do?

I thought I’d write a little code to help remedy my little situation.  Ofcourse I in no way consider myself to be capable of writing a coherent sentence in the English language, much less good code but I’ve never let that stop me in either case… so if the code makes you wince, don’t say I didn’t warn you (also feel free to comment).

So to accomplish my evil deed I decided to write an IHttpModule and change the unwitting users mind for them (also please excuse the nasty formatting, i’m still pretty new to this blogging thing).  Another side note here is that along the way I built a feature to take my master pages and put them in a CustomMasters folder in the 12 hive so they would be available farm wide.

 
class SystemMasterModule : IHttpModule

    {
        public void Init(HttpApplication context)
        {
            context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);
        }
        void context_PreRequestHandlerExecute(object sender, EventArgs e)
        {
            Page page = HttpContext.Current.CurrentHandler as Page;
            if (page != null)
            {
                if (page is PublishingLayoutPage || page is TemplateRedirectionPage)
                {
                 SPContext.Current.Web.CustomMasterUrl = “/_LAYOUTS/CustomMasters/Standard.master”;
                 SPContext.Current.Web.MasterUrl = “/_LAYOUTS/CustomMasters/Standard.master”;
                }
                page.PreInit += new EventHandler(page_PreInit);
            }
        }

 So in this section I’ve inspected the request to see if the user in question has requested a publishing page… if they have I set the master page. There’s really not much else going on here but I’ve found out that publishing pages can be a very specific pain in the ass so they get their own section.

void page_PreInit(object sender, EventArgs e)
{
List<string> safeMasterFiles = new List<string>();
safeMasterFiles.Add(“simple.master”);
safeMasterFiles.Add(“ActivityUIMasterPage.master”);
safeMasterFiles.Add(“dialog.master”);
safeMasterFiles.Add(“layouts.master”);
safeMasterFiles.Add(“pickerdialog.master”);
safeMasterFiles.Add(“sspadmin.master”);

try
{
Page page = sender as Page;
if (page != null)
{
string redirectURL = “http://mySharePointServer/landing.aspx”;
string matchString = “newsbweb.aspx;/teams/”.ToLower();
if (!string.IsNullOrEmpty(matchString))
{
string request = page.Request.RawUrl.ToLower();
List<bool> isMatch = new List<bool>();
List<string> req = new List<string> (matchString.Split(new char[] { ‘;’ }));
foreach (string match in requestMatch)
{
if (request.Contains(match))
{
isMatch.Add(true);
}

else
{
isMatch.Add(false);
}
}
if (!isMatch.Contains(false))
{
page.Response.Redirect(redirectURL);
}
}

if (page.MasterPageFile != null && !safeMasterFiles.Contains(page.MasterPageFile))
{
if (page.MasterPageFile.Contains(“application.master”))
{
page.MasterPageFile = “/_LAYOUTS/CustomMasters/Standard.master”;
}
}
}
}
catch
{
}
}
 

Alright theres a lot going on here really. First and foremost I’m creating a List for all of my safe master pages. This is important! Not all master pages are equal, some of them do very specific things and are not always worth modifying! For me, and the requirements of the governance model created by the farm administrator, I didn’t need to make every last master look exactly the same… only 90% of what the end user sees. The next major piece is my favorite .  We set a redirect path and capture the request event to see if that pesky user is trying to make a new site under one that they own.  In my case the user owned sites all live under a managed path of teams; so basically what is happening here is that I am feeding the code a set of conditions and telling it if the user requests a page that matches /teams/ AND newsbweb.aspx (which is the aspx page for creating new sites) then they need to be redirected to the root of my SharePoint farm.  This is not however the last stop for this particular governance train.  Finally ratchet through all of the master pages, making sure not to step on the toes of one of those safe/utility masters and if the requested page doesn’t need either one of those or is a publishing site I go ahead and set it to a particular master file.

So that’s part one in a nutshell.  The next step is to create property bags for the blocked sites so that the farm admin can leverage our redirect to block out any number of request combinations according to our governance plan… but that’s part 2 Also if anyone sees any obvious errors (or just dumb coding) please let me know. ofcourse all comments are welcome.

<Nickel />

What exactly do I code you ask?

Don’t be coy I heard you ask all the way over here. For the past 3 years or so I’ve been mostly working with SharePoint but I’ve been known to work on Sitecore and a smattering of other languages. I’d like to think that the grey (or gray if you will) area between admin and developer is mostly my strong point but I really have yet to prove that.

At any rate beer is calling and I’ve run out of interesting coversation with this text box but hopefully there will be more to come.