Sitecore Glass

Sitecore Glass is an Object-Relation-Mappper (ORM) for Sitecore items. A common ORM that you may have worked previously would be Linq to SQL. Sitecore Glass helps in referencing Sitecore data item properties by using strongly typed C# objects. It is an open-source project and more information and tutorials are available from their official website.

Step 1 : Install Sitecore Glass for domain project

Sitecore Glass Mapper is available as NuGet package from the official Nuget feed server.
Assuming you have setup the ‘MyProject.Domain’ as per the previous post of the blog series, add a reference to the ‘Sitecore.Kernel.dll‘ within ‘MyProject.Domain‘ project:

Then add the official package via NuGet:

Remove the ‘App_Config‘ and ‘App_Start‘ folders from the ‘MyProject.Domain‘ project and add a custom class file as ‘Models.Generated.cs‘

Step 2 : Install NuGet package for main project

Install the same NuGet package for the ‘MyProject‘ , which is your main MVC project.

As of now, upon successful installation, you should see references to Glass.Mapper, Glass.Mapper.Sc and Glass.Mapper.Sc.Mvc.

Step 3 : T4 Templates for Auto-Code Generation

As a starter, download the T4 templates as provided by the HedghogDevelopment github repository .

Navigate to ‘TDS.Master’ project properties > code generation tab and check the box for ‘Enable Code Generation’. A folder will appear in the VS tree view as ‘Code Generation Templates’.

Copy the downloaded T4 Templates files (with extensions .tt) that you downloaded from github within that folder and include them in the project via VS.

Set the Target Project as ‘MyProject.Domain‘

Set the code generated file as ‘Generated.Models.cs‘

Set the base name as ‘Models‘

Set the header transform file as glassv3header.tt

Set the base project transform file as glassv3item.tt

When you hit save, the Models.Generated.cs should give you auto-generated code for the ‘Sample Item‘ template as below:

This is pretty amazing if you are doing it for the first time as now you can auto-generate your Sitecore data template properties and reference them in your main project as strongly typed objects. Every time you make a change to Sitecore templates, all you have to do is right-click the TDS.Master project, do a sync with Sitecore and it will update the code base. You can also ‘Re-Generate code for all items‘ as shown below:

Adding reference to Glass mapper and configuring TDS project with code generation will make sure that any field name changes that you make in data templates are reflected back in the code. If there are any compilation issues due to referencing make sure you .NET version is correct.

We are all done in setting up the project locally, the next step is to add our project to a choice of our source control so it can be shared with rest of the team and with our build server. This will be explained in the next blog post.

Over past few years with Sitecore, I have worked with various technical teams to deliver Sitecore powered websites. Sometimes we all are located in the same office, but most of the times, we are located in different offices and in different countries.

Part of my job role is to make sure that all of the development work is ready for testing (QA) at agreed time intervals (end of development sprint).

Quality Assurance (QA) is an important part of delivering any project and when a QA team member discovers a defect in the system, my usual conversation with the QA team member goes something like this:

QA : “Naveed, this feature is not working on the QA site?”

Me: “Hey John (the fellow developer who did the original code), can you check why is it not working on the QA website?”

John: “I am not sure, all my code is checked-in and it works on my machine as expected!”

If you have worked on a Sitecore project, you must have had a similar conversation. The reason we have this conversation is because the deployment was done “manually”, which is an unreliable and error-prone process. A file or a package can very easily be missed during the deployment or a wrong version of a file can be deployed.

Moreover, the “manual deployment” process is very time consuming and it will increase the development cost. A typical Sitecore project may have numerous environments like QA, UAT and Production and each environment may have multiple CM and CD servers. As each server may be configured differently and may have different set of config files or config settings, the “manual” deployment process becomes even more complex. So you can see the “manual deployment” process, which started with one QA server, can quickly become very time consuming (read costly).

In an ideal world, what we would like for a Sitecore powered project, is that if someone has written a piece of code and/or updated Sitecore items, it should work on their local machine, it should work on the QA server (or any other non-production servers) and it should work on the production servers. The effort required should be minimal and nothing should be missed during deployment process. And for audit purposes every deployment should be documented.

Automated Deployments (Continuous Integration)

The best possible way to achieve this to make sure that the deployment process is fully automated from start to finish. All pieces of code and related Sitecore items should be packaged, deployed and published with “one single click” of a button.

To achieve our goal of ‘one-click-deployment’, there are tools and techniques available today (well actually since few years) which we can configure for continuous integrations and automated deployment. This will solve our 2 main issues:

Our deployments will be reliable and consistent.

We will be saving time and money.

If you are still doing “manual deployments” within your organization, it is time to re-think and re-evaluate this process.

The purpose of the blog series is to target newer audience/developers/tech teams, who have never done CI before and take them through a ‘hello world’ type of continuous integration process (automated builds).

Server Architecture

For the automated deployments to work, the code udpate workflow should be as following:

1- Developers should work locally and check-in their code in the source control (use of feature branches, fix branches and pull-requests is highly recommended)

2-Continuous Integration server builds and deploys the code to the QA server

The diagram below shows a typical server architecture for the local and QA environment:

The important thing to notice here is that Sitecore items (templates, layouts, renderings, sub layouts) can be sourced control using tools such as TDS or Unicorn tools. I will be referring to TDS within the blog series.

As a minimum, automated deployment process for the above mentioned QA environment will require three servers :

1 – QA Server – Sitecore CM/CD combined on same instance

2- DB Server – Sitecore SQL server databases and MongoDB

3 – CI Server – TeamCity server for continuous build and deployment

In theory, you can use only server, but it will have performance issues for the QA website.

Tools Stack

The tools stack that I will use to demonstrate the process in the series is as below :

There are other tools that can be used for the dev ops, for example, Jenkins can be used in place for TeamCity. Octopus Deploy can be used solely for deployment purposes, leaving CI server to do one job, that is to build the latest code. The decisions to choose the correct stack tools should be dependent upon your business requirements.

For simplicity purposes and for the newer audience, I will be using TeamCity for both build and deployment processes. Once you get confident with simpler process, you can enhance it/supplement it with different tools as you see fit for your project.

Assumptions for the blog series

I will assume that you starting a new project and have a blank machine/servers with only Windows on it or it is your first day at your new job. You can skip any of the below steps if you feel necessary:

Download and install latest version of Visual Studios on your local machine or VM. At the time of writing this post, I have used VS 2015.

Download and install latest version of SQL Express on you local machine or VM. At the time of writing this post, I have used SQL Express 2014

Download and install TDS for VS2015 (requires commercial license, you can use 30 days evaluation for free)

I will also assume that you have RDP and FTP access to the QA, DB and CI servers as described in the architecture diagram to setup continuous integration.

As mentioned before, the blog series is intended for the ‘new audience’, developers or teams who have never done CI integrations. The series will be pretty detailed and a single blog post will not do any justice, therefore it is divided into smaller logical parts of the setup process all of which will be posted in coming weeks.

Local Sitecore Installation

Assuming it is a new project, the first part will be to install a blank Sitecore on your local machine. There are various options for installing Sitecore on your local machine

You can install using the official .exe installer

You can install using the official .zip file and attaching databases

You can install using SIM module.

You can install using Sitecore Rocks VS extension.

Every developer will have their preferred way for installing a brand new Sitecore website, I mostly prefer official .exe installer and will be referring to this in future posts as well.

Please refer to the official documents for installing the basic Sitecore website and do not forget to do the post-deployment steps.

For the purpose of the blog series, the project will be called ‘myproject‘. Once you have installed Sitecore locally and you can navigate the link http://myproject.local on your machine you are ready for the next step. By default, the installation location will be C:\inetpub\wwwroot\myproject\

In the next part of the series we will setup a VS project locally, configure a publish profile and add XML config transforms.

In almost all the projects I have done in past year or so, a common requirement among the clients have been that they want the ability to add Twitter Pods on pages and also have the ability to change the account name based upon their campaign or department.

For the purpose of the post, I will be using Sitecore CMS and LINQ To Twitter library to show how simple it is to create a Twitter Pod/module.

Let suppose we only want to display top tweet from an account/twitter handle, which is define in the Sitecore CMS

Steps:

1. Create a data template property in the CMS as ‘Twitter Account Name’ or whatever you like

2. Create a standard .NET User Control and lets call it ‘TwitterPod.ascx’

4. As per Twitter API 2.0 you need to get Consumer Key, Consumer Secret, Access Token, Access Token Secret values from http://dev.twitter.com for any applications that you are creating. Log-in there and follow the steps to get these values.

Like this:

One Friday afternoon, I was sitting at my desk and fixing bugs (as usual), a member of sales team came up to me and said

“Hey Naveed, we have this interesting new client and they are not sure about which CMS to go for, they have finalised Sitecore and Umbraco as the last two, can you help”

I replied: “Sure, why not, what are their business requirements ?”

Sales person: “They are medium to large size organisation and have usual requirements like news, events, forums, blogs, video content etc, they want a simple to use CMS with multiple authors and security levels”
I replied: “Ok, Sitecore and Umbraco are both equally powerful in content generation and management, they both are based on .NET stack (.NET,C#,SQL) and both are highly customisable, so far they both can be their potential CMS, do you have more specific requirements ?”

Sales person: “Yes, in future, they would like to integrate with Sharepoint and their back-end CRM system”

I replied :”Sitecore comes with a sharepoint connector out-of-box whereas for Umbraco we have to custom build one. As long as their back end CRM exposes API, we can integrate any of the CMS system with their back end, this will be custom build in both cases, do you have any other requirements ?”

Sales person: “It is not a requirement but in their wish list to have personalised content for different regions or profile history”

I replied: “Sitecore comes with Customer Engagement Platform (CEP) and Online Marketing Suite (OMS) which can make their life easy in future, however, Umbraco lacks these customised modules. So it looks like Sitecore can be their potential candidate for CMS, also do you have any idea about their budget for the website?”

Sales person: “Yes, it’s a five figure sum, not sure what exactly their budget is”

I replied: “If they are tight on budget and can compromise on add-ons then Umbraco would be good to start off with but will have high maintenance cost if they go down the route implementing customised modules. However, paying for Sitecore licenses up front will give them added benefit to use some of the modules out of the box and will have low maintenance cost, I guess best would be to give them a demo of both CMS systems to the client and let them make informed decision”

Sales person: “Sounds like a plan, ok I will let them know, cheers”

Conclusion:

No CMS is right or wrong for your business out of the box, you have evaluate them against your own business requirements for the website. Open source may be cheaper to start off with but will have maintenance costs down the line.

Disclaimer: I have worked with both CMS systems and hold them up in same respect for what they do, I am not a sales person or work for either of the CMS systems, this is just my opinion as a third party developer