This is the 2nd plug post in a series about ALM. If you missed the first one, I encourage you to skip over there, have a quick read, then come back. I’ll be waiting for you.

In the last post, I described the three main pillars of ALM: Visibility, Traceability and Automation. This post will describe in more detail the systems and processes you can put in place to build these pillars and improve your chances of success.

Some Background and Context

At Mercury New Media we use Scrum, so many of the systems and processes we use facilitate this mode of operation. We like to deliver software early and often, so an environment that provides automated builds, a Sprint Backlog dashboard and can surface useful data for meaningful reports is vital for our day-to-day operations.

Establish your ALM Platform

By its very definition, ALM applies to all stages of the application lifecycle; all the way from requirements gathering to a successful production deployment. There are dozens of platform choices out there, and this post is not concerned with helping you find a specific one. All I care about is that you find one that works for you and your team. At Mercury New Media, we use Visual Studio Online (VSO) and its related offerings, because:

  • It’s a single solution, so everything integrates. User stories and sprint tasks link to code check-ins which link to automated builds which link to deployments which link to the reporting on VSO. There are no manual steps (see Automation, folks!) or complicated configurations, it all works out of the box.
  • Pretty much everything we do here is based on .NET, so we’re comfortable in the Land of Microsoft.

Just find one that works for you and go with it.

Step 1: Use a Source Code Repository

The first step is to set up your source code repository. This will be at the center of your ALM. It’s how developers will share their code, and the conduit through which your automated builds (see step 4) will perform their magic.

Step 2: Establish a Branching and Merging Strategy

How efficiently you can branch and merge your code will determine how efficiently your team can deliver code without getting into all sorts of bother.

Clear path in winding roads

My advice is to take the simplest approach that meets your project’s needs. If anything in the world is in need of KISS, it’s your branching and merging strategy. There’s nothing more awful than constantly running into merge conflicts due to an overcomplicated approach.

At Mercury, we use master as our integration branch. When we release code, our release build pulls from master and we throw a tag on there so we have information about where in our source code history the deployment occurred. Our support staff fix issues and make tweaks in a dev branch, and we do sprint work in a branch that’s typically named after the set of features we’re working on.

In this scenario, it’s important that we merge up from master regularly. The more time that passes, the further the code bases move away from each other and the more troublesome merging can be. When work is ready to be released to production, the code is merged down from the corresponding branch back into master. If you’ve been taking my advice (and merging from master regularly), this process should be relatively uneventful.

Step 3: Sandbox Your Developers

Child playing in a sandbox

At its core, a developer (let’s say, for the sake of example, his name is Adam) needs to be able to make fundamental, potentially late-breaking architectural changes without fear of putting the kibosh on the rest of the team. Adam, however, should not have to wait to make his changes until his team is ready to receive them. Conversely, each team member should only receive Adam’s changes when they’re ready for them.

We achieve this Nirvana by sandboxing our developers. In the safety of their sandboxes, no team member has reliance on any shared resources. This mainly applies to, but is not limited to, the application database. It can also apply to other services used by the application, such as 3rd party web services not in the team’s control. I know Adam and…I wouldn’t like to be in his sandbox for fear of what lies beneath the sand ;).

Whether you use database-, model- or code-first strategies, it’s vital that each team member has their own database server for development. Now, if Adam needs to rename a column (which if he did that on a shared application database, the rest of the team would be instantly broken) he can do it in his own time frame. Now, schema changes and the code changes that go along with them can be committed into your source control repository as a single unit. When a team member has committed their latest work and is ready to receive changes, they will get both the schema updates and appropriate code at the same time – no breakage.

Ultimately, this approach will avoid bottlenecks, which are the destroyers of productivity. It isolates team members from each other’s changes until they’re ready for them.

Step 4: Set up your Builds

Every source code branch should have a Continuous Integration (CI) build that runs on every check-in. The build should retrieve the latest source code from that branch in the source code repository, build the code, deploy the application database and run unit tests.

When you’re in an Agile environment, it’s also vital to have a Nightly build. The Nightly build should be running off your active development branch. The build should do everything that the CI build does, plus deploy the application so that the Product Owner and Stakeholders can get their fingers in there and use it.

You should also have a Release build. This will be a manual trigger build that is pushed by the team when the application is ready. It’s important that this is an automated process so that institutional knowledge about how to perform the deployment is in the build definition, not in the team members’ heads or on scratches of paper. Your deployment processes should be repeatable and automated.

If there’s an application database (and there typically will be), each build should be deploying to a different location, and you can use web.config transforms to adjust the connection strings for each deployment.

Step 5: Configure Check-in Policies

In order to sate the 2nd pillar of ALM (traceability), you should define check-in policies. You can use this to mandate, for example, that all code check-ins are commented appropriately, and associated with a Sprint task. By storing this data you will be able to surface all kinds of interesting and useful information, such as tracing code changes all the way back to the User Story for which they were made.


In this post I have talked about how to set up your project development environment in order to effectively support the 3 pillars of ALM.

If you succeed at building these foundations, then you can safely follow the Yellow Brick Road to Emerald City.

Yellow Brick Road to Emerald City

If not, you might find yourself getting harassed by the wicked witch instead.

Wicked Witch

What’s Next?

In the third and final post, I’m going to get down and dirty with specifics. I’m going to be writing code, people, so get plenty of sleep. See you next time.

Out of the box, Sitefinity comes with its own grid system that can be utilized to build the layout of your site or app. You can even use media queries in your theme CSS to mold this grid system into being responsive, if you want. Going this route is tricky though, and your media queries will quickly start to grow, become messy, and you’ll probably run into CSS inheritance issues that could break your layout in unwanted ways.

There is a better way that will solve your own interface development headaches and also provide ease of use for your Sitefinity end user to add layouts that are responsive. They are called Layout Widgets – essentially .ascx file that define the HTML of your responsive grid. You can have as many as you want and they are easy to add to your project via the Toolbox. Since you’re defining your own HTML, you can use any grid system you want – your own, Twitter Bootstrap, Zurb Foundation, or any other interface framework out there – and set any breakpoints you need. In this blog post I’ll walk you through the steps to add your own Layout Widgets, using the Twitter Bootstrap grid as an example.

Step 1: Create Your .ascx Files

These .ascx files can live anywhere in your project. Since the grid is closely tied to your CSS theme, I would recommend placing them in your theme folder. For example, your folder structure might look like this:


In this instance we’re creating a simple 100% width column with Bootstrap (version 3 specifically). The HTML of this file will look like this:

<%@ Control Language="C#" %>
<div runat="server" class="sf_cols row">
    <div runat="server" class="sf_colsOut sf_1col_1_100 col-xs-12">
        <div runat="server" class="sf_colsIn sf_1col_1in_100">

Notice we’re adding the Bootstrap classes (row, col-xs-12) to the already existing Sitefinity classes (sf_cols, sf_1col_1_100, sf_1col_1in_100). I’ve found it to be best to keep the Sitefinity classes intact – otherwise your layout widgets may not render correctly in the Sitefinity admin when editing a page or page template. Also, be careful of any HTML or text you place in these .ascx files, as it will appear on the front-end of your site anywhere you’ve used them.

A more complicated layout widget, with multiple columns and breakpoints, might look like this:

<%@ Control Language="C#" %>
<div runat="server" class="sf_cols row">
    <div runat="server" class="sf_colsOut sf_4cols_1_25 col-xs-12 col-sm-6 col-md-3">
        <div runat="server" class="sf_colsIn sf_4cols_1in_25">
    <div runat="server" class="sf_colsOut sf_4cols_2_25 col-xs-12 col-sm-6 col-md-3">
        <div runat="server" class="sf_colsIn sf_4cols_2in_25">
    <div runat="server" class="sf_colsOut sf_4cols_3_25 col-xs-12 col-sm-6 col-md-3">
        <div runat="server" class="sf_colsIn sf_4cols_3in_25">
    <div runat="server" class="sf_colsOut sf_4cols_4_25 col-xs-12 col-sm-6 col-md-3">
        <div runat="server" class="sf_colsIn sf_4cols_4in_25">

Again, we’re adding our CSS grid classes after Sitefinity’s classes. The difference here is that we have four columns in this layout. We’ve also set three different breakpoints using Bootstrap’s grid — col-xs-12 col-sm-6 col-md-3 — which means the columns will be 100%/one column and stack on a smartphone, be 50%/two columns at tablet sizes, and be 25%/four columns on small desktop and larger screens.

Step 2: Add Your Layout Widgets to the Toolbox

I recommend that you add your Layout Widgets to the ToolboxesConfig.config file manually. The benefit to doing it this way instead of through the Sitefinity admin screens, is that the ToolboxesConfig.config file can be checked into your source control solution, and will ensure your Layout Widgets appear locally, in your staging environment(s), and in your production environment.

The Toolbox file is located in /App_Data/Sitefinity/Configuration/ToolboxesConfig.config. In this file, before the ending tag, is where you’ll be adding your layout widgets. Using our two layout widgets above, the code you’ll need to add is below:

<toolbox name="PageLayouts">
                <add ordinal="1" name="TwoColumns" />
                <add enabled="True" title="Bootstrap 3 Columns" description="Twitter Bootstrap 3 Layout Widgets" ordinal="0" name="Bootstrap3">
                        <add enabled="True" type="Telerik.Sitefinity.Web.UI.LayoutControl" title="100%" description="1 Column (col-12)" cssClass="sfL100" layoutTemplate="~/App_Data/Sitefinity/WebsiteTemplates/MyTheme/LayoutWidgets/Bootstrap/Bootstrap3_1Col_Col12.ascx " visibilityMode="None" name="Bootstrap3_1Col_Col12" />
                        <add enabled="True" type="Telerik.Sitefinity.Web.UI.LayoutControl" title="4x 25%" description="4 Columns (col-3 + col-3 + col-3 + col-3)" cssClass="sfL25_25_25_25" layoutTemplate="~/App_Data/Sitefinity/WebsiteTemplates/MyTheme/LayoutWidgets/Bootstrap/Bootstrap3_4Col_Col3-3-3-3.ascx" visibilityMode="None" name="Bootstrap3_4Col_Col3-3-3-3" />

Here’s the breakdown of the code:

toolbox name=”PageLayouts” and section tags are required, and is the location in which you’ll add all of your layout widgets. The add and tools tags are required to declare your layout widgets.

The first add tag adds a grouping of layout widgets. You can have as many of these as you want, as long as they have a unique name. The ordinal attribute is also important, as that is the sort order if you have more than one set of layout widgets. (In this case, we have two – and we’re telling the build in Sitefinity widgets to come second below our Bootstrap widgets.) The title attribute will correspond to what you see in the Sitefinity admin.

The inner add tags each declare the layout widgets for this group. Again, the title attribute corresponds to the text you see in the Sitefinity admin. Additionally, the description attribute will add a tooltip to the layout widget giving the admin user more clarification. Make sure your path to your layout widget is correct, otherwise you may encounter errors.

If we take the time to add a full complement of responsive layout controls, what appears in the Sitefinity admin will look like the screen capture below:

Sitefinity Layout Options

Since our custom Bootstrap grouping was declared with an ordinal of 0 (zero), it appears at the top and is open by default.


Layout widgets should be a go-to resource for any interface designer working with Sitefinity. We’ve incorporated them into our Sitefinity projects at Mercury with great success — it allows designers to provide our clients with responsive site or app layouts with fewer problems and without sacrificing any control. Additionally, you could provide even more value to your clients by adding in a number of page templates using your custom layout widgets to get them started when they are adding a new page or page template.