We built a website in a day – Pt. 1

Building a website in a day

I don’t mean to say that we build all of our websites in a day, or that we built this one in literally 1 day- but   We’ve all found ourselves in the situation where a website has gone down, and there’s no hopes of bringing it back online. My first real project in the industry revolved around replacing a website with a fast-approaching retirement date (or rather, the OS was hitting end of life and we didn’t have the source code).  Now, you could argue that with proper planning this would never happen, but I would have to disagree. Hindsight’s always 20/20, and no one can reliably predict the future.  Shtuff happens, and when it does happen, you need to be ready to react.

In this series, I really wanted to talk about how we found ourselves able to build a website rapidly, and not necessarily the underlying technology.  You see, over the last six months we’ve been designing and building an Enterprise Accelerator for one of our clients.

4 P.M., Wednesday Afternoon

Tommy pulls us into the war room.  It’s about time to leave for the day, but we know something’s going down.  You just get that feeling.  There’s 4 key members: Cesia Cortes (content analyst), Ben Cato (front end developer), CJ Morgan (back end developer), and myself.  Tommy informs us that a particular website we were going to upgrade and replace this summer is down right now, and we’re the swat team tasked with creating a replacement.  The MVP: create a job board, less than 5 pages, with one of those pages being a list of jobs and another page representing job detail pages.  Lucky for us, our enterprise accelerator can handle that no-problem.

The Plan

At a high level, to execute as fast as possible, here’s what we needed:

• A temporary server, any server really (so long as it’s fast), that has Sitecore, SQL, Mongo, and SOLR installed.
• File system access to that server for all developers.
• Login credentials to Sitecore for everyone.
• A code base, with a solution that can house our layout definition, CSS, configuration, and custom JavaScript.
• Automation to distribute that code base to our temporary server, and our real production infrastructure.
• A design mock of what the MVP looks like, including imagery and various assets.

Of course, for us this all starts with the server.  You see, the only people at Brainjocks, now Perficient, that run Sitecore locally are the back end developers.  For our Front End developers and Content Analysts, they work out of a hosted instance and coordinate the assembly of styling and front end interactions.  We knew that getting the server up and running asap was going to fall on CJ and myself, so we told Ben and Cesia to head home and be prepared to start early in the morning.

It’s time to move!

5 P.M, Wednesday Afternoon

To get the server up and running, we’re required to give the change management organization a heads up.  While they can execute fast, in this case it would have taken a 24 hour turn around to have something we can use.  That’s no good in our case, because we want to be done in 24 hours.  The solution, instead, was to use our own Google Cloud hosting service and spawn a pre-setup machine image.  I spawned a Google Cloud mid-size server that already had SQL Server, IIS, and MongoDB up and pre-configured.  Once it was awake, CJ remoted in and installed Sitecore and SOLR, gave it a static IP, and set up a temporary DNS record.  If you don’t have the capability of spawning a server to work out of on a whims notice, take this as a suggestion.  It may have taken 4 hours to do it from scratch (if you know exactly what to do), but we were able to do it in less than 2.  That’s 2 hours saved, which adds up over time.

While CJ was working on the Sitecore Installation, I went ahead and initialized the git repository.  You see, in the SCORE world we have this concept called scaffolding, and this is the first critical concept of the Enterprise Accelerator.   Scaffolding is a collection of Powershell scripts and other automation techniques that create a new solution for you and bring it up to a certain state.  If you’re curious as to what this may look like, you can watch a video here:

The Scaffolding

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

You see, the cool thing about Scaffolding is that you can copy and change SCORE’s default to suit your own needs.  As part of this client’s enterprise accelerator project, we cloned and modified 3 aspects:

• The SCORE Scaffolding Visual Studio template.  You can download that from here if you want to take a look.
• The SCORE Scaffolding Sitecore scripts (e.g., the ‘New Site’ button).  That is also downloadable from here.
• The SCORE nuget feed’s init.ps1 script (you can see it in the SCORE nuget distribution on your local packages directory).  As part of package installation, Nuget will execute any init.ps1 scripts found when the package is installed into Visual Studio.

With the visual studio template, we updated it to align with the client’s organizational naming convention, swapped NUnit for XUnit, added some default build configurations that align with the environment strategy, and added default configuration files that were hooks into the override-able pieces in their Enterprise Accelerator.  I downloaded this template and ran the scaffolding script. 15 minutes later, and I have the skeleton of the new site running on my machine.

The next step was to get SCORE, SCORE UI, SCORE Bootstrap UI, and Enterprise Accelerator installed into my freshly scaffolded Sitecore installation.  Again, the SCORE portions of this are exactly what you see in the video above.  The Enterprise Accelerator piece follows the same patterns as well.  That Enterprise Accelerator wasn’t built overnight either, over the last six months we’ve been working on a Helix based component layer that meets the business needs on what this organization is trying to accomplish.  It features integration points with 3rd party systems (such as Career Builder for retrieving job information), form components, search components, globalization enhancements, powershell authoring tools (including new site scaffolding!), and a slew of other features.  We set up some automation around the Enterprise Accelerator to have a Nuget package generated when we’re ready to release new versions, and that Nuget package has a customized version of the init.ps1 script inside of it so that it can self-install.  Long story short, this step is simple: open Nuget Package Manager and install all of the Nuget packages (SCORE, SCORE UI, SCORE Bootstrap UI, Enterprise Accelerator) into the solution.

By the way, for those of you unsure of what ‘Nuget’ is, it’s a mechanism that back end developers use to distribute compiled and tested code.  You can think of it as a ‘feed’ of code updates and changes over time.

Now that we have a running instance of Sitecore with a solution behind it, the next step is to get the Sitecore content items setup.  Websites in Sitecore have a lot of moving parts: templates, renderings, layout definitions, placeholders, settings, rules, content tree structure, etc.  To get all of these moving parts to line up by hand is tedious, takes a long time, and is error prone.  Instead, our Enterprise Accelerator comes with a nifty feature: the ‘New Site’ button.

All it does is execute a Powershell script via Sitecore Powershell Extensions.  That script prompts you for one thing: What’s the name of the website?  After confirming your input, the script uses a series of branch templates to create a standardized set of Templates, Placeholder Settings, and Content Tree items.  It sets up custom rules in the settings area, and ties your sites content structure to the solution structure that we scaffolded earlier.  Pretty nifty, right?  Oh, and the Visual Studio solution scaffolding comes with configuration files that are setup to align with the paths created in Sitecore.  Slick!

After scaffolding the Sitecore assets, the final step is to pull my Sitecore items into source control, and commit the initial repository.  You can find those details in the video above.

7 P.M, Wednesday Night

By this time we now have a Sitecore installation on a server, and a code base ready to be installed on that server.  This next part is another critical concept of the enterprise accelerator: automation, or how-we-get-the-code-from-here-to-there.  We’ve seen this done with a slew of tools before (TeamCity, VSTS, Bamboo, etc), and none of this is unique to Brainjocks, now Perficient.  As it turns out, Team Development for Sitecore is a critical piece in our setup.  With Team Development for Sitecore, we instruct it to Generate Update Packages on Build in specific build profiles.  The other ingredient that makes this work is Sitecore Ship, which is a CI service layer than can install update packages over HTTP communication.  At this point, the task is straightforward:

1. Get Sitecore Ship up and running on the server
2. Create a job to install SCORE, SCORE UI, SCORE Bootstrap UI, and Enterprise Accelerator onto the server
3. Create a job to install the freshly scaffolded solution onto the server.

Now, I know I’m minimizing step #2 & 3 here, and I really shouldn’t.  Something you should be cognizant of though, is that (like the server images above), most build automation is the same boilerplate:

For the accelerator layers, the steps are:

1. Download distribution from Nuget (which should include a .update package generated by TDS)
2. Use Sitecore.Ship to install the Nuget package.  If you are in VSTS, there’s a Sitecore Ship step that can be downloaded from the plugin library.  If you’re using Teamcity, you can use CURL to post the .update files to the ship endpoint manually.

And for the solution itself, the steps are:

1. Checkout Solution
2. Stamp the build number on it
3. Restore Nuget Packages
4. Compile Solution
5. Copy license.xml into place for Sitecore FakeDB
6. Run Unit Tests
7. Take .update packages and POST them to Ship (same as step 2 above).

So really, this step involves copying a known automated build and changing it’s variables to align to this new website.  The funny thing about automation is that establishing the pattern is difficult, but copying the pattern is straightforward.  If you are skipping out on automation, it’s likely the reason why your development cycles are slow.  Seriously, don’t skip on automation.  If you can’t clone your production code and generate a hotfix release in under an hour, then you need to rethink your operational strategy.

8 P.M., Wednesday Night

At this point, we’re ready to pack it up for the night.  In 4 hours, we accomplished quite a bit:

• Set up a server for Cesia and Ben to work out of
• Set up a code base for the new site
• Set up automation to push that code base to the server
• Created a test page to verify everything’s working

And the moral of the story?  Eliminate churn on boilerplate.

1. Don’t set up servers from scratch.  Instead, set up an image that has all of the stuff you typically install for a sandbox.  Will it be production ready?  No, but it will be enough to unblock your team.  Even better if you can do this with somthing like Docker!
2. Don’t set up your code base from scratch.  Instead, embrace automation and have powershell do it for you.  Create a solution structure that you like, and replicate it for all of your projects built upon your accelerator.  The additional beauty here, is that all of your solutions will have a very similar setup and code organization, which leads to less ramp up time for new developers.
3. Do automate, and don’t set up your automation from scratch.  Instead, have a handful of pre-defined build templates that you can easily and quickly reference.

Now, I realize not everyone has these things (accelerators, automation, server images, etc) in place today… but remember, you’re not in a firedrill right now.  Take the time to establish and set this practiced up, so that the next firedrill doesn’t have to be one.