SharePoint Saturday CT 2014: Improving the SharePoint Development Process with Continuous Integration

This past Saturday (November 8th), I attended and presented at SharePoint Saturday Connecticut. It was my first time up in the Hartford area, and I wasn't quite sure what level of attendance/participation to expect. I was blown away! The number of attendees and sponsors was well above what I expected, the audience was very engaged throughout the day, and I heard almost entirely positive feedback for the many sessions and the overall event. It was a tremendous success.

It was especially fun to catch up with so many of my Slalom colleagues from other offices. Jared Matfess was a co-organizer of the event and brought along a number of his colleagues from the Hartford office. Three of us from New York came up for the event, as did three consultants from our Boston office. It was an impressive showing for Slalom and a great opportunity to see one another.

Just like at SPS New Jersey a few months ago, I was scheduled to speak at the very end of the day. I wasn't sure how much of an audience I'd get, and was very pleasantly surprised to have the room nearly full! There were many great questions and comments, and I was really happy with how the session went overall. Hopefully everyone learned something!

Without further ado, here are the updated slides I presented on Saturday. In addition, I've pulled out the links from the slides and listed them underneath the presentation for easier access.

• The Daily WTF: Source Control Done Right
• QUnit JavaScript Testing Framework
• Chutzpah JavaScript Test Runner
• JavaScript Unit Tests on Team Foundation Service with Chutzpah
• SharePoint 2010 with Windows PowerShell Remoting Step by Step
• Client-side SharePoint PowerShell
• My Continuous Integration Blog Posts

SharePoint Saturday NJ 2014: Improving the SharePoint Development Process with Continuous Integration

Last weekend I had the pleasure of speaking at SharePoint Saturday New Jersey. Held at the Rutgers University Busch Campus, this was SPS NJ's second year, and my first in attendance (unfortunately in 2013 it was the same weekend as our annual office retreat). It was a great day, with a couple hundred people in attendance and many excellent presentations (including four others by my Slalom colleagues!).

I had one of the last sessions of the day, speaking about Continuous Integration and how it can benefits SharePoint development projects. It was my first time presenting on the topic, and although I thought it went pretty well I definitely received some valuable feedback which I will use to adjust prior to SPS Connecticut in November.

My slides reference a number of helpful articles and frameworks, which I'll list again below so you don't have to go through and find them all:

• The Daily WTF: Source Control Done Right
• QUnit JavaScript Testing Framework
• Chutzpah JavaScript Test Runner
• Integration Chutzpah with TFS
• SharePoint 2010 with Windows PowerShell Remoting Step by Step
• Client-side SharePoint PowerShell
• My Continuous Integration Blog Posts (more on the way!)

And here are the slides. Please leave any questions or feedback in the comments below!

TFS Build Options Explained: Build Triggers

Team Foundation Server provides administrators with five different triggers when creating or editing a build definition. Each option is useful in the right scenario, so it's helpful to have a good understanding of each.

Manual
This is the only option which does not rely on any form of automation. Builds using a definition with the manual trigger must be explicitly requested by a developer.

Continuous Integration
When this trigger is selected, a new build will be queued every time a new changeset is checked-in. This is CI in its purest form (hence the name)!

Rolling Builds
While the CI trigger is simple and great, it has an Achilles' heel. Say, for example, that your build process takes 10 minutes to complete. And say that your development team is very busy and suddenly a dozen changesets are checked-in. You've suddenly got 12 builds in the queue and the last check-in won't be included in a build for two hours! That's no good. The Rolling Builds trigger solves this problem by grouping check-ins together. After one build using the definition completes, a new build will be queued with ALL of the changes checked-in since the previous one. Optionally, you can even set the trigger not to queue more often than every specified number of minutes. This way you can ensure that no changes will be stuck in limbo for too long between being checked in and being validated with a build.

Gated Check-in
While the Continuous Integration and Rolling Builds will help catch errors soon after code changes are checked-in, the Gated Check-in trigger will prevent a changeset from being committed (and therefore from ever impacting other developers) if it is not first validated by a successful build. When a developer performs a check-in, his/her changeset will be merged into a temporary shelf and a build will be queued. If the build is successful, the changes will then be committed to the target branch. Otherwise, they will be rejected and the developer must resolve the errors before attempting another check-in. The Gated Check-in trigger also provides an option to perform the validation build after a specified number of check-in attempts, rather than every time; this is similar in concept to the Rolling Build trigger.

Schedule
Scheduled builds will be queued and run at the specified times, regardless of when any individual check-ins occurred (although by default the build will be skipped if no check-ins have occurred since the last one). You may choose any number/combination of days, but can only select a single time of day to queue the build. If, for example, you wanted to schedule builds for 9:00 AM on Mondays and 2:00 PM on Thursdays, you would need to create two separate build definitions.

TFS Build Options Explained: Queue Processing

When creating a new build definition in TFS, one of the first options you're required to select is what type of queue processing you would like the definition to follow. There are three options: Enabled, Paused, and Disabled.

Enabled
When queue processing is enabled, builds using the definition may be queued by either a manual user action or by an automated trigger (such as a gated check-in or scheduled build). The build controller will then run the builds in order of priority.

Paused
When this option is selected, builds can again be queued either manually or automatically. However, the requested builds will sit in the queue until an administrator manually forces them to start. This may be useful when the same build definition is utilized by large, disparate teams and builds are either requested frequently or take a long time to complete.

Disabled
When queue processing is disabled, the definition can never be used to queue or start a build. Selecting this option prevents triggers such as Continuous Integration or Gated Check-in from being used with the definition. This setting is really only useful as a way to archive a build definition or to prevent its accidental use (perhaps a build administrator would re-enable the definition prior to using it for a Production release).

The Dos and Don'ts of Modal Windows

Modal windows can be very useful in web development, enhancing the user experience by presenting small pieces of information both quickly and beautifully. But there are drawbacks to using modals, and times when they really shouldn't be used at all. Let's review some common use cases:

DO use a modal window to display media in a useful way.
I've been a big fan of Lightbox for many years. For flipping between images in a gallery or showcasing a streaming video from a news article, modal windows are great because they are fast, navigable, and keep the original page content in the background (even though its typically shaded out to provide better focus on the modal).

DON'T use a modal window for an entire web page.
I've seen many clients push for the use of modal windows simply because they seem flashy (especially when accompanied by animation effects) or because they are considered "responsive." But loading an entire web page in a modal window isn't any faster, it wastes precious screen space, and it can be awkward for users. Assuming you're site is easily navigable (it better be!) then it's always better to load larger pages in the browser themselves.

DO use modal windows for quick interactions, such as login screens, alerts, or contact forms.
These are meant to quickly grab users' attention, serve their purpose, and get out of the way. Put a "login" link in the header of every page, and a "contact us" link in the footer, and have them each launch a small modal window for their very specific purposes. Once the information is filled out, the modal vanishes and the user is right back where they expect to be.

DON'T use modal windows on responsive pages which need to play nicely on mobile devices.
I hate modal windows in the mobile experience. Phone screens are small enough, and mobile friendly pages should be lightweight enough, that the advantages of using a modal window on a desktop site really don't apply on mobile devices.

It's also very important when considering the use of a modal window to consider any implications to the background web page. If Page A launches Page B in a modal window, can the user take action on Page B that might impact the validity of the content on Page A? For example, picture a "shopping cart" page. What if clicking on an item in the cart opened the product information in a modal window, and that product information page included the "Add to Cart" option. After clicking that and closing the modal, wouldn't you expect the quantity in your cart to have been updated? It's not impossible to make that happen, but it's an example of when choosing to use a modal window may require more work than you initially realize to ensure a positive user experience.

This was by no means a comprehensive list, but touched on some of the best uses for modals as well as the common pitfalls I see on the internet and when working with clients. Let me know if you agree/disagree with anything above, or if there are any other major pros/cons of using modals I may have missed!