Creating a branch from another branch is very simple and easy. When working with a Continuous Integration system, however, your branch is supposed to be monitored, built and deployed to a place people can access and test it.

A branch and its servers with Continuous Integration

The following image illustrates a scenario where multiple developers are working at the same branch, and a second branch is used as a basis to deployments. The blue boxes at the right represents servers with specific purposes. Being now a Sitecore good practice to develop and test in scaled environment, all environments will have two nodes, one for Content Management (CM) and another for Content Delivery (CD).

The Continuous Integration server monitors the branch “All developers” and deploys changes to DEV (at every change) and QA (manually). When the time for a deployment comes, the work is merged to Deploy Branch. The Continuous Integration server will then make the last integration to the servers “Deploy-CM” and “Deploy-CD”, where things can be tested for the last time before the actual deployment.

The Problem with this approach is that all developers are pushing their modifications to the very same branch, and thus deployments must carry everything at that branch (except of course, if very granular merges are made, but that can also be tricky and error-prone). To enable a better safe separation, the following setup is proposed.

Multiple Branches

The image below now shows a second branch, with its respective DEV and QA servers. Now each developer can make their work at their own branch, keeping a physical separation that guarantees one developer’s work won’t interfere with the other.

The image also shows that branch “Dev1” (the older branch) were used to create branch “Dev2”, which guarantees that both branches are identical at that point in time. Obviously, each branch will have their modifications from that time on, and the code integration is now a bit harder to be executed. As time passes, each branch will be more and more different, bringing the need to a more careful exercise during the integration, executed at the “Deploy” branch.

Deployments and Reverse Merges

When all developers were working at the same branch, the act of checking in their changes were the integration itself. Continuous Integration server would push it to the servers, and integrations were continuously made due to the same code base. But now with physically separated branches, developers must communicate and keep their branches as much in sync as possible. The following images shows a sequence of deployments and reverse merges, that would keep both Dev branches in sync while sustaining their separations.

Image 1 – First Deployment (by Dev1) and Reverse Merge (by Dev2)

Image 2 – Second Deployment (by Dev1) and Reverse Merge (by Dev2)

Image 3 – First Deployment (by Dev2) and Reverse Merge (by Dev1)

At that time I was proposing a post-building event triggering robocopy, which did the trick for that particular situation. Some time later I had access at my team to “CopySauce”, a software that keeps watching your code base for changes, deploying immediately after the change is detected. Interestingly, a couple weeks after that Sean Holmesby (author of CopySauce) commented on my post, suggesting his tool as an alternative for Robocopy.

One thing that I like with that approach is the file auto-deployment, because it very nicely mimics what was (in my opinion) the only advantage of that old strategy of having both your solution code and the sitecore webapp at the same place: avoiding IIS restarts when changing non-compiled files (JS, CSS, markup, etc). And better than Robocopy, this won’t even require a compilation to be triggered – files are transferred when you save it.

Sitecore Rocks – Folder Syncronization

The only issue I have with that is the obvious need to start CopySauce to have it acting. Since we are already using Sitecore Rocks for some development tasks, as soon as I knew about the existence of a native feature that is similar to CopySauce I decided to give it a chance. If you already have Sitecore Rocks installed in your Visual Studio then you have all you need to start working.

Setup of your solution

Configuring the folder synchronization on your solution is a bit different than CopySauce – instead of having a XML file Sitecore Rocks offers you some visual aids integrated to Visual Studio. Please check the official documentation for details on how to properly configure your project.

You can specify what folders in your solution to start syncronizing with the right click menu

Then select one of the two syncronization methods

Folder Synchronization – literally

One thing which in my opinion is a weak of this tool is that, as it own name states, it can only be used to keep folders synchronized. As a consequence, you cannot keep files at the root in sync between solution and the webapp, having to manually deploy these.

This would typically affect you web.config at least, so avoid placing things that frequently changes in your solution at the root folder of your Website project.

Only folders can be kept in sync

At the solutions I’ve tested these are the folders I had to keep in sync to start taking advantage of the tool

Performance

The tool also starts deploying your changes as soon as you save it, although I have noticed sometimes a certain delay, generally not bigger than 10 seconds tho, which is acceptable compared to a normal build.

In short, to take advantage of CSS styling over SVG files, you must throw the XML content of the SVG file, directly into the HTML markup. So instead of the traditional <img tag:

<img src="image.svg"

You must throw inline the content of the SVG file, which will be something like:

<svg ...> <ellipse class="chair" .../> </svg>

In Sitecore that means you can’t use the standard sc:Image control to render the content of an Image Field – that will render your SVG as an <img HTML tag, which can’t be touched by CSS styling…

Usercontrol

In order to have something that is compatible both with CSS Styling and Sitecore’s Page Editor mode, my proposal is to have a custom asp usercontrol like this:

Image.ascx

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="Image.ascx.cs" Inherits="Layouts.UserControls.Image" %>
<sc:Image runat="server" ID="scImage" />
<asp:Literal runat="server" ID="litImage"></asp:Literal>

 Image.ascx.cs (Codebehind)

namespace Layouts.UserControls
{
 public partial class Image : UserControl
 {
   /// <summary>
   /// Component's Field
   /// </summary>
   public string Field { get; set; }

   /// <summary>
   /// Component's Item (Default=Context)
   /// </summary>
   public Item Item
   {
      get { return _item ?? Sitecore.Context.Item; }
      set { _item = value; }
   }
   private Item _item;

   protected void Page_Load(object sender, EventArgs e)
   {
     // When editing in Page Editor mode, always use an <sc:image
     // If no field is set, escape and let it break
     if (Sitecore.Context.PageMode.IsPageEditorEditing || string.IsNullOrEmpty(Field))
     {
        ShowScImage();
        return;
     }

     // Escape if field is not found
     var referencedImageField = (Sitecore.Data.Fields.ImageField)Item.Fields[Field];
     if (referencedImageField == null)
     {
       ShowScImage();
       return;
     }

     // Get referenced image - Scape if image is not found
     var imageItem = referencedImageField.MediaItem;
     if (imageItem == null)
     {
        ShowScImage();
        return;
     }

     // If this is not an svg use a normal <sc:Image
     var imageMediaItem = (MediaItem) imageItem;
     if (!imageMediaItem.Extension.ToLower().Contains("svg"))
     {
        ShowScImage();
        return;
     }

     ShowSvgImage(imageMediaItem);
 }

 public static string GetMediaUrlWithServer(MediaItem mediaItem, Item item = null)
 {
    item = item ?? Sitecore.Context.Item;
    var options = new UrlOptions { AlwaysIncludeServerUrl = true, AddAspxExtension = false };
    var itemUrl = LinkManager.GetItemUrl(item, options);
    var mediaOptions = new MediaUrlOptions { AbsolutePath = true };
    var mediaUrl = MediaManager.GetMediaUrl(mediaItem, mediaOptions);
    return itemUrl + mediaUrl;
 }

 private void ShowSvgImage(MediaItem mediaItem)
 {
    litImage.Visible = true;
    scImage.Visible = false;

    // Get string from Image Stream
    var stream = mediaItem.GetMediaStream();
    var reader = new StreamReader(stream);
    var svgString = reader.ReadToEnd();
    reader.Close();
    stream.Close();

    // Get SVG tag from string

    // No SVG tag found - fallback to <sc:Image
    if (!svgString.Contains("<svg"))
    {
       ShowScImage();
       return;
    }

    svgString = svgString.Substring(svgString.IndexOf("<svg",StringComparison.Ordinal));
    litImage.Text = svgString;
 }

 private void ShowScImage()
 {
    litImage.Visible = false;
    scImage.Visible = true;

    scImage.Item = Item;
    scImage.Field = Field;
    ReflectAttributesToControl(scImage); 
 }

 private void ReflectAttributesToControl(WebControl control)
 {
    foreach (string key in Attributes.Keys)
     control.Attributes[key] = Attributes[key];
 }
}

Streaming

The proposed solution makes use of Streaming for better performance, so rendering times are not affected.

How to Use

Now we have our custom image rendering control that renders inline SVG images when you are in Preview or Normal mode, and is compatible with Sitecore’s Page Editor mode.

To use, first you have to register the Usercontrol:

<%@ Register TagPrefix="custom" TagName="Image" Src="~/layouts/UserControls/Image.ascx" %>

Then use it just like you’d do with a standard sc:Image control:

<custom:Image runat="server" ID="imgSvgImage" Field="My Field Name" />

At the code behind you can also access the properties “Field” and “Item” just like the normal Image control:

imgClear.Item = Sitecore.Context.Item;

And that’s all!

1. You can easily lose track on your customizations;
2. Upgrading Sitecore for a newer version may become harder;
3. During development you may be forced to turn your LDAP module off, basically undoing the setup of your providers, which is not straight-forward.

After facing these issues a couple times I decided to look for a better approach.

Using Includes

Biggest limitation is by far the need to update your Web.config, as the changes are not in the Sitecore portion and thus cannot be automatically patched by files in your /App_Config/Include folder. Best you can do is to create patches with the configurations, then include them at the Web.config.

Step by step

1. Add the LDAP connection settings to your ConnectionStrings.config:
   

   <add name=”ManagersConnString” connectionString=”LDAP://yourldapserver.com:389/DC=your,DC=domain” />

2. At your Web.config, find your <system.web> section and comment out your <membership>, <roleManager> and <profile> nodes – these will be all replaced by includes;
3. At the same level you commented out, add a <machineKey> node as covered at the official documentation:
   

     <machineKey validationKey=”BDDFE367CD36AAA81E195761BEFB073839549FF7B8E34E42C0DEA4600851B0065856B211719ADEFC76F3F3A556BC61A5FC8C9F28F958CB1D3BD8EF9518143DB6″ decryptionKey=”0DAC68D020B8193DF0FCEE1BAF7A07B4B0D40DCD3E5BA90D” validation=”SHA1″ />

4. Still at this level let’s add three includes for Membership, RoleManager and Profile providers:
   

   <!– Includes –>
   <membership configSource=”App_Config\AD\Membership.config” />
   <roleManager configSource=”App_Config\AD\RoleManager.config” />
   <profile configSource=”App_Config\AD\Profile.config” />

5. As well as the three includes for disabling the module. We let it commented for now, which makes the module enabled:
   

   <!–
   <membership configSource=”App_Config\AD\Membership_Disabled.config” />
   <roleManager configSource=”App_Config\AD\RoleManager_Disabled.config” />
   <profile configSource=”App_Config\AD\Profile_Disabled.config” />
   –>

6. You have also to add your mapped domain(s) to App_Config\Security\Domains.config:
   

   <domain name=”ad” ensureAnonymousUser=”false”/>

7. Now create a folder called “AD” at App_Config and drop the six config files that are zipped at this link:
   – AD-configs – Don’t forget to review all files (except the “_Disabled.config” that stores the native Sitecore configurations) to make sure you username, password and domains are corretly set!

Now when you want to turn the module off you just have to comment out the lines from #4 and uncomment #5 – pretty easy.

Here is the question:

In Sitecore, how would you organize architecture and static files – mainly CSS and javascript files – during development of the following two levels menu?

The first level shows an Image and a Title and starts closed:

When the user hovers a block at Level 1, a second part is displayed showing items on Level 2:

Answer

Your static CSS and Javascript files, like in any other web application, must be loaded somehow. At the project we are working, we have a bundle and minification process in place, responsible for loading, minify’ing and caching the files so everything loads faster.

But you can load files the old way:

<script src="myscript.js" type="text/javascript"></script>

The implementation itself can be split into two different challenges:

1. Front-end development
   We clearly have a good front-end work here, some dynamic behavior when user hovers around level 1, the look and feel and everything. Basically all HTML markup, javascript and css stylesheets can be prepared without having Sitecore specifically in mind;
2. Back end development
   All necessary to enable the content edition of menu items, and make it work dynamically at a page, including:
   • Step 1 - Upload your javascript and CSS files somewhere at your site filesystem (Eg: “/assets/js” and “/assets/css“), then load them somehow (traditional, bundle, etc);
   • Step 2 - Define your data structure (templates and fields) to support the content management. It all depends on your requirements – let’s have the following two possible scenarios:
     • Scenario 1 - You may want to feed the menu with pages and subpages you already have in your content tree. In this case you would just use your existing data:
       
     • Scenario 2 - Or you may be asked to create a dedicated data structure, not pages themselves but pointing to real pages. This data structure would have the following format:
       Menu Item Level 1
       Menu Item Level 2
       And you would keep the item somewhere outside your page’s content tree:
       
   • Step 3 - Create the component/sublayout that implements the menu feature. Following the same two scenarios above:
     • Scenario 1 - In this case you would use the Sitecore API to pragmatically get the Home item, using Children items to render menu’s level 1, and their grandchildren rendering level 2:

       var homeItem = Sitecore.Context.Database.GetItem("/sitecore/content/Home");
       var levelOne = homeItem.Children.ToList();
       foreach (var itemLevelOne in levelOne) {
          // This item represents a Level 1 menu block
          var title = itemLevelOne.Fields["Title"].Value;
          var image = itemLevelOne.Fields["Image"].Value;
          var levelTwo = itemLevelOne.Children.ToList();
          // ... do whatever you need with Level 1
          foreach (var itemLevelTwo in levelTwo) {
             // Here you work your Level 2 item
             var titleLevelTwo = itemLevelTwo.Fields["Title"].Value;
          }
       }

     • Scenario 2 - This implementation would be very similar to the first scenario, except that you would have to start at your repository folder (Eg: /sitecore/content/Lists/Menu) instead of the Home item.