Before we debate the definition of a microservice I should clarify - we are actually decomposing to small(ish) vertical web applications bounded by cohesive business functionality. That title didn’t have quite the same ring to it!

We look to utilise the benefits of a microservice architecture but do accept some constraints.

Why did we do it?

Our Sitecore monolith has grown large and cumbersome over many years of optimising for time to market rather than the long term health of the platform.

It’s easy to jump to microservices and not all monoliths are a bad design choice, however ours has grown to exhibit two key constraints.

• The first is how well the application supports our ability to deliver new functionality to customers. We must release everything together as one large unit of deployment. This process is slow and therefore we tend to release infrequently.

• The other constraint is development scale. As teams write more code the solution becomes more difficult to maintain, and cost of change gradually increases. Importantly we limit the number of teams who are able to work in parallel.

What were we looking to achieve?

We looked to solve these problems by unlocking two main capabilities of the platform:

• Move towards smaller, quicker, incremental isolated units of deployment.
• Partition the platform so that cross functional teams are able to work and release code independently of each other.

The distributed monolith anti-pattern

Team autonomy is crucial in a distributed architecture. A release should have no impact on other teams. If we need to release Application B due to updates to Application A we expose ourselves to the drawbacks of the original monolith but also have all the challenges of a more distributed architecture.

How quickly do we start realising our objectives?

We use new business initiatives to determine which areas of the application to partition. In deciding which area of the platform to focus on we then determine how to partition, i.e. how big should each application be, which business functionality should each cover.

Usually we would partition by bounded context unless there was a technical capability we were looking to leverage for a particular application. For example an advantage of smaller units is that each application is independently scalable and fault tolerant. We might decide high volume areas of the site should be isolated. It can also be prudent to consider how often different areas of the site change, and which areas change together.

It is not necessary to decompose the whole monolith to start realising value from the new architecture. After releasing one or two applications in production we were able to assign ownership to individual teams. Applications are able be released quickly and independently of the monolith. Teams are able to make incremental updates to those applications.

In starting to realise these outcomes we allow ourselves time to iterate and learn. The architecture can evolve and we can improve based on past learnings.

We are able to further decompose (a now smaller monolith) when the business is ready, again using business initiatives as a catalyst to break out new applications.

What does this look like?

There are a couple of approaches to decomposition, we opted for a common technique known as the strangler pattern.

Effectively the original monolith remains unchanged at first. We build new applications in separate codebases and utilise a reverse proxy (CDN in our case) to redirect requests to the new application. The proxy also provides a convenient mechanism for rollback and risk management via traffic splitting.

Each vertical slice of functionality has two key components:

• First a micro frontend utilising a Headless CMS (Sitecore JSS, which was the enabler for this architecture).

• Each Micro frontend is served by a lightweight Restful API (effectively a BFF variation) and proxies commands and queries into backend service layers (not maintained by our teams).

Continuous deployment and automation are the backbone of this architecture.

Notice those unpleasant red lines? Dependencies on the monolith are not ideal, but we try to treat Sitecore as a service (headless CMS) in this model. This is one of the constraints vs true microservices and something we will discuss next.

What we learnt

No architecture is perfect, we make a compromise somewhere and hope to not close the door on modifying the direction based on what we learn.

In this scenario we have both the challenge which comes with a distributed platform whilst also working around some of the constraints that Sitecore forces upon us, most notably the shared database. In a distributed architecture a shared database is usually a big red flag as it couples applications together. True independence and isolation are much more difficult to achieve.

Sitecore is the constraint here, however there are short and long term techniques we can leverage to solve this problem.

Short term we did a few things to enable release independence:

• Ensure all content updates are backwards compatible.
• Partitioned the content so each app owned an area of the Sitecore tree. We have an automated content deployment process and run automated integration tests on a staging environment.
• To expose new data to the frontend applications via JSS’s Layout Service API you usually need to write code in your Sitecore solution (the monolith in the visualisation above). This obviously creates a release dependency on the monolith. To solve this we created an dynamic content based resolver more powerful and flexible than those Sitecore provides out of the box. There are also options to leverage GraphQL.

Longer term we have other options too.

Applications which don’t need to be content editable (the content changes infrequently) are able to consume their content from another source if it makes sense to simplify in this manner. We can also look to a future Sitecore SaaS offering (potentially looking to move further towards a more MACH esque architecture), utilise techniques such as Static Site Generation, or a content cache close to the application. Any techniques we utilise can vary per app based on the context and business capability exposed via that application.

Other challenges

There are truly shared areas of concern in both API and Frontends such as authorisation which need consideration.

There are challenges in ensuring areas of the code and patterns remain consistent where you want consistency between codebases and therefore between teams. In a true microservice ecosystem autonomy would usually include teams having ownership of technology choices.

The frontend architecture becomes more complex. I will likely follow up with another post on frontend architecture as it can be easy to become stuck. There will be code you will want to package and version to share between apps which can be a challenge when a primary concern is ensuring applications remain loosely coupled. There will also be UI that teams will want to reuse between apps.

It’s all too easy to abstract too early and bake the business logic of multiple applications into a UI component. Where do you draw the line between DRY and prudent duplication? One approach can be to utilise atomic design principles and treat shared UI as ‘dumb’ Lego which can be consumed by applications who then bake in their own domain logic within the application.

Other areas of concern are source control, continuous integration and deployment (A container based deployment strategy can be extremely powerful). There is value in utilising the Monorepo pattern but also reasons why this approach might not be right for your context.

If you got this far I hope some of this was useful, the journey for this architecture is far from over.

Docker desktop is a quick and easy way to run a Kubernetes cluster locally on Windows 10 allowing Windows users to experiment with Kubernetes. If you have Windows subsystem for Linux installed you can use this as the docker backend which provides better performance than Hyper-V.

Kubernetes RBAC (Role based access control) is a Kubernetes resource which allows us to define policies to determine which actions specific users are allowed to execute at cluster and namespace level. e.g pod creation.

If you are not familiar with RBAC there are many fantastic resources which explain RBAC fundamentals which are worth reading via a quick Google.

Setting up a user and authenticating with Kubernetes

Users cannot be added to a cluster through an API call, so user accounts have to be externally managed and then authenticated by the cluster. There are a few methods available to authenticate with the cluster.

I decided to focus on X509 client certificates. We first create the private key for a user and a certificate signing request. We ask the cluster's CA to certify the certificate. We then authenticate using the signed certificate.

Create the certificate signing request

I did this in Ubuntu via WSL2.

openssl genrsa -out myuser.key 2048  

openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser/O=myusergroup"  

Next we ask the Kubernetes API to sign the CSR.

Create a cert-sign-request.yaml

kind: CertificateSigningRequest  
metadata:  
  name: myuser
spec:  
  request: <TO REPLACE>
  usages: ['digital signature', 'key encipherment',
    'client auth']

Head back into Linux (WSL) to create the Request string (< TO REPLACE>). There are presumably methods to do this all in windows but this was easiest for me.

cat myuser.csr | base64 | tr -d '\n'  

Back in windows:

kubectl apply -f .\cert-sign-request.yml  
kubectl certificate approve myuser  

Next we need to extract the base64 encoded signed certificate from the Kubernetes API.

kubectl get csr myuser -o jsonpath='{.status.certificate}'  

In windows copy this into a txt file and generate the crt.

certutil -decode cerbase64.txt myuser.crt  

To authenticate with Kubernetes as myuser we need 2 things, the crt we generated above and also the key file which if you did the same as me was created on Linux. If using WSL2 you can locate the key file easily enough here: \\wsl$\<distro>\home\<me>

Impersonating our new user

kubectl config view will show we are currently authenticated as admin the docker-desktop user.

To add the new user we add a new context with the credentials.

kubectl config set-credentials myuser --client-key myuser.key --client-certificate myuser.crt --embed-certs

kubectl config set-context myuser --cluster docker-desktop --user myuser  

We can now run commands as our user to test RBAC:

kubectl --context=myuser get pods  

You will see an error - as the user has no permissions.

Creating RBAC policies

To test RBAC let's create a simple nginx pod definition ready for later - nginx-pod.yaml:

apiVersion: v1  
kind: Pod  
metadata:  
  name: nginx-pod
  labels:
    name: nginx-pod
spec:  
  containers:
  - name: nginx-pod
    image: nginx
    ports:
    - containerPort: 8080

Running kubectl apply --context=myuser -f ./nginx-pod.yaml will throw a permissions error.

Let's create an editor role which will allow myuser permissions to create this pod - pod-editor-role.yaml

kind: Role  
apiVersion: rbac.authorization.k8s.io/v1  
metadata:  
  name: pod-editor
rules:  
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "get", "list", "watch"]

kubectl apply -f pod-editor-role.yaml  

To assign the member to the role we create a role binding - myuser-editor-binding.yaml:

kind: RoleBinding  
apiVersion: rbac.authorization.k8s.io/v1  
metadata:  
  name: myuser-editor
subjects:  
- kind: User
  name: myuser
  apiGroup: rbac.authorization.k8s.io
roleRef:  
  kind: Role
  name: pod-editor
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f myuser-editor-binding.yaml  

Now if we create the pod as myuser - success!

kubectl apply --context=myuser -f ./nginx-pod.yaml  

This is really scratching the surface of RBAC and not meant to be a complete overview. Again our friend Google produces many fantastic resources if you wish to get stuck in furthur.

The problem

You'd think it would be fairly straightforward to use VueJs and Sitecore together. However the complexity is in splitting the template from the component definition. To render fields from Sitecore (and to enable page editor), we need to have our markup in .cshtml files which means the template cannot live in a .vue file along with the Javascript code.

Possible solutions

Caveat - As per the last post this is exploratory code, mainly because I couldn't find much help online to solve this problem. The solutions outlined here though are much more complete than the previous post which I received quite a few questions about - so hopefully more to get started with now!

Note: I have updated to Typescript in these examples and used the webpack config from https://github.com/microsoft/TypeScript-Vue-Starter. I will Provide links to my github with all the code from these examples at the end of the post.

Option 1 - X-Templates

The previous post focused on X-Templates as a solution to the problem as these give us separation of markup and component code. https://vuejs.org/v2/guide/components-edge-cases.html#X-Templates

The big problem with the X-Template solution from the previous post is that if you have multiple of the same component on a page the first variant will be rendered for each instance. (As both have the same Id).

Here is a solution to that:

app.ts

/* Components */
import HelloWorld from "./Components/HelloWorld/hello-world";

new Vue({  
    el: `#app`,
    components: {
        HelloWorld
    }
});

HelloWorld.ts

import Vue, { VNode } from "vue";  
import { Component, Mixins, Prop } from "vue-property-decorator";

@Component({
    name: "hello-world"
})
export default class HelloWorld extends Vue  
{
    @Prop({default: "Example"})
    testprop!: string;

    mounted = () => {
        console.log("Props: " + this.testprop);
    }

    data = () =>
    {
        return {
            message: "Hello from component data!"
        };
    }

    methods = {
        testClick: () => { console.log("I have been clicked!"); }
    };

    template: string = "#hello-world-template";
    static renderIndex: number = -1;

    render(createElement): VNode {
        HelloWorld.renderIndex += 1;
        this.template = `#hello-world-template_${HelloWorld.renderIndex}`;
        return createElement(this);
    }
}

HelloWorld.cshtml

@model MyNamespace.MyModel

<hello-world testprop="This is a message from props"></hello-world>

<!-- RenderIndex needs to come from your c# controller -->  
<script type="text/x-template" id="hello-world-template_@Model.RenderIndex">  
    <div>
        <h1>@Sitecore.FieldFor(m => m.MyField)</h1>
        <div @@click="testClick()" class="container">
            {{ message }}
        </div>
    </div>
</script>

Layout.cshtml

...
<body>  
    <div class="main" id="app">
        @Html.Sitecore().Placeholder("full-screen")
    </div>
    <script type="text/javascript" src="~/Scripts/bundle.js"></script>
</body>  
...

There is one last problem to this approach. The x-template definition needs to live after the closing tag of the Vue app i.e <div id="app"> or you will get the following error: Property or method "message" is not defined on the instance but referenced during render. Make sure that this property is reactive, either in the data option, or for class-based components, by initializing the property

(If you want to know why this happens: https://stackoverflow.com/questions/49193378/why-does-position-of-x-template-section-matter-for-vue-templates-to-work-with-da)

You could easily use a simple html helper to poke the x-template script within each cshtml file to the end of the layout page.

Option 2 - Using slots

Interestingly a buddy of mine, Chris Howson, also had this problem to solve and uses a clever approach utilising slots (https://vuejs.org/v2/guide/components-slots.html#Scoped-Slots) to solve the problem. I'll link to Chris' blog post about this once he's had time to create it.

This is arguably a cleaner solution than the x-template approach. The only downsides are the extra code you need to write in render and some people might argue using slots in this way is a little strange. For me, it's a great solution.

app.ts

/* Components */
import HelloWorld from "./Components/HelloWorld/hello-world";

new Vue({  
    el: `#app`,
    components: {
        HelloWorld
    }
});

HelloWorld.ts

import Vue from "vue"  
import { Component, Mixins, Prop } from "vue-property-decorator";

@Component({
    name: "hello-world"
})
export default class HelloWorld extends Vue  
{
    @Prop({default: "Example"})
    testprop: string;

    mounted() {
        console.log("Props: " + this.testprop);
    }

    message: string = "Hello from component data!";

    methods = {
        testClick() { console.log("i have been clicked!"); }
    };

    render() {
        return (<any>this.$scopedSlots).default({
            message: this.message,
            testClick: this.methods.testClick
        });
    }
}

HelloWorld.cshtml

<hello-world testprop="This is a message from props" v-slot="data">  
    <div @@click="data.testClick()">
        <h1>@Sitecore.FieldFor(m => m.MyField)</h1>
        <div>{{ data }}</div>
    </div>
</hello-world>  

Github examples

I'll update this post with links to github code containing even more complete examples shortly. Hopefully the code above gives some fresh ideas for tackling this problem.

It seems obvious but you really want to avoid a content change taking down your website.

No matter how well you code the site, null checking, version checking your items etc.. if a rouge item is published, or key data unpublished then your whole site could grind to a halt.

There are a few solutions to this such as:

• Workflow. - Of course put all/key content through an approval process. This can be a great solution.
• Staging publishing target. - This can work nicely alongside workflow, ensure all content is checked on a non public facing publishing target first.

Another option

Another option which can work standalone or alongside the ideas above and also helps mitigate human error, such as content just being approved without being checked is to run some UI tests on publish.

Tests on publish

So the idea is actually rather straightforward.

• Content editor publishes to stage.
• The publish action invokes a background Cypress (JavaScript UI test runner) job (http://cypress.io) to run some UI tests on your staging target. These tests can check key journeys of your website are still functional. I.e Homepage is up and displays correct content, the checkout is working as expected.
• When the user wants to publish to live they see a status of the last test run which gives them confidence in the publish. If the test run failed, then don't publish.

How can I achieve this?

There are many ways to build this. In my prototype I combined a node API server with a small update to the publish dialog. I'm sure it can be improved upon but it works fairly nicely.

The node server

https://github.com/daveaftershok/cypress-node-api-windows

Once up and running exposes a number of endpoints to execute Cypress tests. If you don't know how to use Cypress it is great piece of software please try it out.

The publish script

https://github.com/daveaftershok/sitecore-test-run-on-publish

Feel free to edit this code as you wish.

In this post I will share things to consider when planning an upgrade and also talk about the process we went through to upgrade and deploy a new version of Sitecore to production.

Planning ahead

Estimating a Sitecore upgrade can be a difficult task. The effort required can vary significantly based on the complexity of your solution. Below are some things to consider when estimating the effort and time an upgrade will take.

• What version of Sitecore are you upgrading from and what version are you upgrading to? Have you mapped out what the upgrade process will be? Can you use the Upgrade migration tool? (more on this later)
• How much custom Sitecore code is there in the solution?
• How many support patches are there in the solution?
• How do you perform a full regression test? What is the testing effort?
• Do you have adequate test coverage to be confident in the solution post upgrade?
• How complex is the solution (i.e more things can break, higher likelihood more bugs / issues will be found)
• What is the current state of the Web and Sitecore configs?
• How many non production environments will you need to upgrade and deploy the new version to?
• What does the path to live look like?
• Do you use any external modules? For example XDB, WFFM, EXM - and what is the upgrade path for these modules?
• What is the state of package dependencies within the solution? i.e Do different projects have different versions of the same library?
• How will you develop new functionality alongside performing an upgrade? - The elapsed time between first creating your upgrade code branch to actually deploying the upgraded solution to production will likely be a number of months.

Our process...

Here are some things we did and learnt whilst upgrading from Sitecore 7.2 to 9.

Reworking the configs

As we were working with a fairly old solution before we did anything upgrade-wise we spent about 2-3 weeks reworking our configs. This involves moving all changes to transforms and Sitecore patch files leaving us with out of the box Sitecore and web configs.

With any new projects I would suggest doing this from the start.

We used file comparison tools to compare the 'compiled' Sitecore config (/sitecore/admin/showconfig.aspx) before and after the changes were made. Even after doing this we missed a few bits so be wary testing effort is still required. There are also Sitecore modules to help you do this e.g.: https://marketplace.sitecore.net/modules/sitecore_configbuilder.aspx

Consider contingency time to fix any issues which might arise.

As a side note to further improve your config setup Sitecore 9 now supports rules based configuration - more about that here: https://jammykam.wordpress.com/2017/10/17/rules-based-configuration/

The express migration tool and how we dealt with configs during the upgrade

In the past the way to upgrade Sitecore was jumping from version to version, with all sorts of fun along the way. Sure the upgrade path allowed you to skip a few versions to get to your target but it was still a painful process.

The express migration tool is much better. It migrates your content from any version since 6.6 to version 9 at the time of writing. Check latest compatibility here: https://kb.sitecore.net/articles/400952

It worked really well for us. However it is not perfect - for example it did not migrate some renderings correctly which resulted in broken presentation details which we only noticed during testing the site. This can be fixed with content packages / unicorn etc (or in our case SINJ scripts which are run after the site has been upgraded.

The tool can also migrate configuration... which we chose not to do. Instead we upgraded our configs manually, which after reworking (above) was not difficult.

As we were not utilizing any additional modules we were able to disable most of the provided patch files in the App_Config folder.

To get a better feel for the effort required one thing we like to do right at the start is a quick and dirty upgrade to get a feel for the sort of problems we might encounter when we do the real thing and to answer some of the bulleted points listed above.

State of the solution and support patches

Luckily we have most of our custom code well documented. You will need to factor in time for fixing any problems that might arise in custom Sitecore code on the newest version of Sitecore. e.g custom pipelines, handlers, helpers etc.

We also document support patches added to the solution. It's easy to forget why Sitecore.Support.12345.dll lives in your bin directory and what problem it is solving! Again validating these problems are still fixed after upgrade needs to happen. We were able to remove nearly all our support patches as the bugs they were implemented to fix were resolved in the newer version of Sitecore.

You might also find after upgrading you have dependency hell in terms of referenced assemblies not playing well with each other. This can take an age to fix.

Upgrading non prod environments

You will need to factor in time for upgrading non production environments. Perhaps you will need to spin up a second QA environment for Sitecore 9 testing as your original QA environment is needed for ongoing development. What about CI and CD - is this a factor? Do you need to run automated tests against 2 versions of Sitecore now until you go live?

Testing

I've mentioned testing quite a bit.. and for good reason. It's so easy to underestimate the testing effort that goes into an upgrade.

We have a whole suite of automated UI tests covering most of the business use cases which we run overnight. This really helps flush out any upgrade issues. We also have a super QA team who manually test the site and specifically the CMS itself which is not covered by our tests.

One example of something which caused us problems was that the way Sitecore stores raw time changed which caused some of the code to become unhappy. Expect small things like this which can crop up and do need identifying and fixing.

Other modules

We were lucky. No XDB, no WFFM and no EXM. This makes the upgrade process much easier.

If you do have other modules to upgrade factor in time for this. It's easy to underestimate the complexity of upgrading these modules and identifying and fixing any issues than might occur.

XDB is notoriously hard to upgrade.

EXM and WFFM - You may have to go through lots of different install steps although the express migration tool does state it can help with WFFM.

This can be painful and time consuming.

Also consider older versions of WFFM are not supported in 9.1.

The live deployment

For zero downtime we utilize blue green deployments. We spun up new Sitecore 9 stacks and then switched traffic via Akamai after we've completed our 'offline' testing against the new stacks.

In a normal deployment we have a short content freeze of say 1 hour during which we backup the databases and use these backups in creating the new environments.

When migrating from Sitecore 7 to 9 we have one major change from our standard release process - the Sitecore 7 database needs updating to Sitecore 9.

We agreed a content freeze from 4pm the day before the release.

We created a new EC2 instance to perform the migration using the express migration tool via a number of custom powershell scripts. It time we needed to migrate a database from 7 to 9 we simply re-run these scripts changing a few params which determine the environment to upgrade.

The process worked like this:

• Powershell script is run which creates a backup of the live Sitecore databases (core and master) at 4pm.
• Next it restores these databases to our upgrade box.
• We then upgrade these databases using the Express migration tool.
• We have a blank Sitecore 9 instance installed onto our upgrade box. We login to Sitecore and perform a full site publish.
• We push the new migrated databases to S3 where they can be picked up by our deployment process when spinning up the new prod environment.

I've had a lot of questions about this so have written a follow up to this post you can find here: http://www.daveleigh.co.uk/using-vuejs-in-sitecore-and-asp-net-mvc-razor-pages/

Background

We have a very large, (and now pretty old!) enterprise web application utilizing Sitecore MVC and Angular 1.

Over the years Angular has worked well for us in some areas but has shown weaknesses in others. Some of the side effects from it's 2 way databinding, it's global state management and its over complicated digest system are just a few headaches we've head. This leads to the codebase being relatively complicated for new team members. Working on a team which adds new developers frequently Angular works but it could be better.

Caveat to the above, using a combination of Typescript with Angular has really helped us, and abstracting as much away from the angular layer as possible also helps simplify things

VueJs.

VueJs has a fantastic feel to it. it is an easy to pick up, intuitive component based Javascript framework. It feels very much like Angular to use, it's syntax is very similar but overall Vue is much less opinionated. It has improved many of the pain points that I found problematic in Angular and has also introduced concepts seen in React such as the virtual DOM. In terms of performance it is also much better (Angular suffers from an incurable performance issue, as the page gets larger and larger it quickly becomes slower and slower.)

Vue enforces a one way data flow between components meaning there is only one source of truth and global state is managed via a Redux type pattern - Vuex.

Why not Angular 2+?

I'm sure Angular 2 is also a good option but it's something I haven't really focussed any time on. However as a team we are also exploring Angular 2+.

What about React?

Using React with sitecore is certainly doable. The main complexity arises when you need to solve the issue of combining JSX and sitecore field renderers.

There are a few blog posts which provide some answers... and of course you could also use JSS.

https://sitecoreblog.alexshyba.com/sitecore-and-react-how-hard-can-it-be/

http://sitecorepro.blogspot.com/2017/08/sitecore-and-react-simple-integration.html

https://www.sitecorenutsbolts.net/2017/07/04/Sitecore-React-Getting-Started/

What about JSS

If you can use JSS it is certainly be worth exploring. It will, in Sitecore 9.1 come out of beta and looks fantastic.

However there are many scenarios where you might not want to use JSS and ours was one of them.

This isn't a JSS post, if you want more info about JSS - http://jss.sitecore.net.

Integrating Vuejs into a Sitecore solution

A caveat.. I've used Vue many times before but never at enterprise scale so this post really documents a prototyping effort.

These are the main problems I wanted to solve:

• Installing Vue into existing Sitecore solution and setting up build.
• Using Vue in Sitecore controller renderings (razor files).
• Rendering Sitecore field data into Vue components with experience editor support.
• Communication between different Vue components in different renderings.

Installing and building Vue

This is pretty straightforward.

1. create package.json

yarn init

2. Install the following dependencies

yarn add vue
yarn add webpack webpack-cli --dev
yarn add vue-loader vue-template-compiler vue-style-loader css-loader --dev
yarn add @babel/core @babel/plugin-syntax-dynamic-import @babel/preset-env babel-loader cross-env css-loader --dev

3. Configure webpack and babel

The way I've always built my Vue applications is via webpack. Below is my basic dev config. Note it does not include any production build steps (minification, bundling etc etc) which are essential so don't forget those.

'use strict'
  const webpack = require('webpack')
  const path = require('path');
  const { VueLoaderPlugin } = require('vue-loader')

module.exports = {
  mode: 'development',

  entry: [
    './vue/app.js'
  ],
  output: {
    filename: 'main.js',
    path: path.resolve('./vue-build')
       },
       resolve: {
             alias: {
                    'vue$': 'vue/dist/vue.esm.js'
         }
   },
  module: {
    rules: [
      {
        test: /\.vue$/,
        use: 'vue-loader'
      },
      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: [path.join(__dirname, 'src')],
      },
      {
        test: /\.scss$/,
        use: [
          'vue-style-loader',
          'css-loader',
          {
            loader: 'sass-loader',
          },
        ],
      },
      {
        test: /\.css$/,
        use: [
          'vue-style-loader',
          'css-loader',
          {
            loader: 'css-loader',
          },
        ],
      },
    ]
  },
  plugins: [
    new webpack.HotModuleReplacementPlugin(),
    new VueLoaderPlugin()
  ]
}

note: the 'resolve' section is a real gotcha and is required to build Vue in the style we will be coding later in this tutorial. Don't forget to add it to your webpack config!

And my .babelrc

Babel is a tool to transpile newer Javascript language features (e.g. ES6) into older versions of Javascript (e.g. ES5) that work in current and older browsers or environments.

{
    "presets": [
      [
        "@babel/preset-env" ,
        {
          "modules" : false
        }
      ]
    ],
    "plugins": [
      "@babel/plugin-syntax-dynamic-import"
    ]
  }

Note: If you use typescript you won't need babel. For this prototype I didn't introduce typescript but i would if/when we use Vue outside of a prototyping context.

Update your package.json

...
"scripts": {
    "build": "webpack --config build/webpack.config.dev.js",
  },
...

Run with

yarn build

(Although it won't work until we create './vue/app.js' in the next section..)

Using Vue in Sitecore controller renderings

Create a rendering in Sitecore, for this example I created a simple view rendering with the path:

/vue/Components/HelloWorld.cshtml

Below is the contents of that file.

@inherits System.Web.Mvc.WebViewPage

<!-- component mounted here -->
<div id="vue-hello-world"></div>

<!-- component template -->
<script type="text/x-template" id="hello-world-template">
    <div>
          <h1>Hello Vue</h1>
          <div class="container">
               {{ message }}
          </div>
    </div>
</script>

<!-- This is our webpack output - this should live with your other scripts in the foot of the page not at component level.. but we are prototyping... :) -->
<script type="text/javascript" src ="/vue-build/main.js"></ script>

There are many ways to define Vue templates, to play nicely with Sitecore we are using the x-template option.

Next we need an entry point for our Vue application

/vue/app.js

import HelloWorld from './Components/hello-world.js'

This just imports all our components, each parent component is it's own Vue instance.

The hello-world component

If you've used Vue before you will know a vue component typically has a .vue extension (hence the webpack loader) and has the following makeup:

<template>
    <div>Hello world</div>
</template>
<script>
export default {
    name: 'hello-world',
    data() {
        return ...
    }
</script>
<style>
    .blah {
    }
</style>

Using .vue files doesn't really work for us, we need our markup to come from the rendering.

Instead we can create plain old js files:

/Components/hello-world.js

import Vue from 'vue'

let component = {
   name: 'hello-world',
   template: '#hello-world-template',   
   data()
   {
       return {
             message: "Hello World!"
       }
   },
};

// Initialise Vue
if (document.getElementById("vue-hello-world")) {
new Vue({
   el: '#vue-hello-world',
   render: h => h(component)
});
}

export default component

And that's it! If you run the webpack build the hello world Vue component should render.

To render child components:

The syntax to achieve this also caught me out but here's how it done:

hello-world.js

import AChildComponent from './hello-world-child.js'

let component = {
    name: 'hello-world',
    template: '#hello-world-template',
    components: { 'hello-world-child': AChildComponent },
...

hello-world.cshtml

...
<script type="text/x-template" id="hello-world-template">
        ...
        <hello-world-child></hello-world-child>
    </div>
</script>
...

<!-- child component template -->
<script type="text/x-template" id="hello-world-child-template">
    <div>
        <h1>Hello!</h1>
    </div>
</script>

and you would create the child vue component hello-world-child.js. It doesn't need referencing in app.js webpack will sort this out for you.

Vue.Component

As we can't use .vue files, Vue components are another option in .js files.

However coding a Vue application is this style does come with caveats as documented here:

https://frontendsociety.com/why-you-shouldnt-use-vue-component-ff019fbcac2e

Rendering Sitecore field content

Using this method we are simply adding markup and Javascript to standard controller renderings (razor files) which keeps a clean separation of server and client code. So whichever method you use to render sitecore fields should work just fine.

Vuex

You can just use Vuex as usual. Create an instance of the store and ensure each Vue instance (there is one per component in this setup) references that same store.

In this post we will revisit the basics of docker and then cover the basics of Kubernetes by completing the following tasks:

• Create a simple Node Js app, using Redis as a persistence store.
• Dockerize the app.
• Deploy the app to Kubernetes and explore two kubernetes resource types - pods and services.

In the next post of this series we will cover some more advanced topics.

The Node Js app

First lets setup our env.

npm init
npm install express --save-dev
npm install redis --save-dev
npm install body-parser --save-dev

If you're new to Node --save-dev will add the dependency to our package.json. Later our docker container will be bootstrapped by running npm install thus installing required dependencies into the container

Note - Please don't worry if this app won't run locally - you probably won't have redis installed - but thats expected.. this is what containers are for.

Create an app.js

const express = require('express'); 
const bodyParser = require('body-parser');
const app = express();

app.use(bodyParser.json()); 
app.use(bodyParser.urlencoded({ extended: true }));

const redis = require('redis');
const client = redis.createClient('6379', 'redis');

app.get('/', (req, res) =>
{
    client.hkeys('items', function (err, reply)
    {
        res.send(JSON.stringify(reply));
    });
});

app.post('/api/additem', function(req, res) 
{
    client.hmset('items', req.body.name, req.body.data, function (err, reply)
    {
        res.send(`Added ${req.body.data}.`);
    });  
});

const port = 3030;

app.listen(port, () =>
{
    console.log(`server listen port: ${port}`);
});

This is a trivial app which does three things:

1. Create an express webserver which listens for incoming requests on port 3030.
2. If we receive a get request to the root we return a response with all the item keys in the redis store.
3. If we receive a post request to /api/additem we add to the store.

Dockerize the app

Before we jump into Kubernetes we need to create a container for our app. Containers are based on images, and to create an image we need a dockerfile.

# The base image
FROM node:latest
# Create a directory on the container
RUN mkdir -p /my/app    
# Set the working directory
WORKDIR /my/app  
# Copy package.json to the working directory
COPY package.json . 
# Install node dependencies
RUN npm install
# Copy app.js into the working directory 
COPY app.js .       
# Expose the port 3030 on the container
EXPOSE 3030      
# Run the app
CMD [ "node", "app.js" ]    

To build an image from this dockerfile:

docker build -t daveleigh/demo .

Note: Your local environment needs docker installed - I am on ubuntu. https://www.docker.com/community-edition

We then need to make this image availble to our Kubernetes stack for later so we push it to a container registry.

docker push daveleigh/demo

To do this with your own account sign up at https://hub.docker.com/.

You could run this container on your docker enabled host:

docker run -d --name myapp -p 3030:3030 daveleigh/demo

However it would error as redis is not defined yet. Also that's not the aim here, we are going to deploy this and redis to our Kubernetes stack.

Finally... Kubernetes

Kubernetes provisions and manages containers running on multiple hosts. It can scale pods, manage the health of the stack (spinning up new pods if existing ones crash), automate deployments, load balance... the list goes on.

Declarative yaml/json files define the stack and resources are provisioned by the master on to worker nodes on our cluster via the kubectl Api.

The first resource we will create is a pod. A pod is a unit of deployment and scale and will contain one or more containers that may expose ports. Containers within a pod can talk to each other via localhost.

In our example we will create a pod for our app, and a separate pod for redis. However in a real world scenario if you were using redis as ephemeral cache you may have both the web app and redis in the same pod so they scale together.

Lets define a pod for our web app, and to do this we create a yaml file.

web-pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    name: web
    app: demo
spec:
  containers:
    - image: daveleigh/demo
      name: web
    ports:
      - containerPort: 3030

This file is pretty self explanatory. We define the type of resource to create and some meta data. Note labels are arbitrary so you can specify anything you want. The purpose of labels is for other resources should they need to target your pod, for example a load balancer might target pods where app = demo.

Within spec we define the containers the pod will host and the ports each container exposes. Simple.

Lets also define a redis pod:

redis-pod.yml

apiVersion: v1
kind: Pod
metadata:
    name: redis
    labels:
    name: redis
    app: demo
spec:
    containers:
    - image: redis:latest
        name: redis
        ports:
        - containerPort: 6379

Provisioning the pods

Let's deploy our pods onto our cluster.

kubectl create -f web-pod.yml -f redis-pod.yml

You should see the following output:

pod "web" created
pod "redis" created

To view the pods we have just asked Kubernetes to create for us:

kubectl get pods

You will notice the web pod has errored! We can see the details of the error:

kubectl get logs web

Don't panic just yet.. and it's not quite time to swear at me for wasting your time.. this is expected and brings us onto..

Services

Our pods need to be able to communicate with each other and potentially the outside world.

There are two main types of service, internal and external. Internal services allow our pods to communicate within the cluster. External services allow access to our pods from the host.

Lets create an internal service:

redis-svc.yml

apiVersion: v1
kind: Service
metadata:
    name: redis
    labels:
    name: redis
    app: demo
spec:
    selector:
    name: redis
  type: ClusterIP
  ports:
   - name: http
     targetPort: 6379
     port: 6379

This will create a new Service object named 'redis' which targets TCP port 6379 on any Pod with the "name=redis" label.

Type 'ClusterIP' exposes the Service on an internal IP in the cluster. 'targetPort' is the port the container exposes in the pod and 'port' is the port used internally by consumers (it is the port your service listens on inside the cluster.)

kubectl create -f redis-svc.yml

Then recreate the web pod:

kubectl delete pod web
kubectl create -f web-pod.svc

Now the app should be up and running, however we can only access it internally. To test the app we can hop into the shell within our web pod:

kubectl exec -it web /bin/bash

Now lets try using the api:

curl -d "name=item1&data=test" -X POST http://localhost:3030/api/additem

You should see 'Added item1'. Great!

Before we finish up, lets make the app available from outside the cluster.

External Service

Lets use our app via the public IP of one of our worker nodes. The only missing piece of the puzzle is to create an external service to allow requests to the host to access our pods.

web-svc.yaml

apiVersion: v1
kind: Service
metadata:
    name: web
spec:
    selector:
    app: demo
  type: NodePort
     ports:
    - name: http
        nodePort: 31001
      port: 80
      targetPort: 3030

Creating our service of type 'NodePort' exposes the Service on the same port of each Node in the cluster.

The 'nodePort' defines the port on the node.
Internally all the consumers of the service can talk to the service on port 80.
the 'targetPort' is 3030, i.e the port the container exposes in the pod.

kubectl create -f web-svc.yml

If you want to see details about any of the resources you have created:

kubectl describe svc web

You should now be able to access your app at: http://PublicIP:31001.

To conclude

So we've taken our tiny app and deployed it onto a Kubernetes cluster. Hopefully this gives you a glimpse of what Kubernetes has to offer. This example is of course trivial but I hope it helps show the power of Kubernetes and how it could help you run your applications in production situations.

Speaking of more production like situations we will cover persistance in pods which is a hot topic in a later post and in the next post we will create a replica set and a rolling deployment.

What we will cover today:

1. What is Kubernetes and when would I use it?
2. What is cluster & setting up a cluster on AWS/Azure/Google cloud/Digital Ocean/Bare Metal
3. What is the Kubectl (spoiler alert, its the Kubernetes Api used to manage your resources).

What is Kubernetes?

If you've not used Docker before, I would suggest covering that first, trust me it's worth it.. i'll wait.

Great, so if like me you love the concept of containers, but now have the challenge of managing them in production Kubernetes is for you.

In the past whilst spinning up and linking docker containers you may have used docker compose. It's fairly simple and allows you to quickly create a number of linked containers on a single docker host (via a docker-compose yaml file). What it doesn't do though is:

• Allow you to deploy containers across multiple hosts (VMs).
• Manage the lifetime and health of each container and provision new containers should existing ones crash.
• Manage scaling, networking, automate deployments, load balancing etc.

This is where Kubernetes (or k8s as it's also known) fits into the picture. (note: Docker swarm was also built to solve these problems. I won't go into Swarm vs K8s in these blog posts.)

(Important) What Kubernetes is not...

It is not the silver bullet (sorry!) to solve all your production infrastructure challenges. You still need to solve those first... yourself. For example, do you need multi master database replication across multiple regions? Well, K8s will not solve scenarios like this for you. However once you have solved such problems conceptually (perhaps a managed database is better than facilitating this via K8s for this scenario) then sure, Kubernetes can provision and manage the lot... easily.

The cluster

A kubernetes cluster contains a master and a number of worker nodes. (Strictly you can have more than one master, but let's not complicate things this early)

Kubernetes provisions your containers across a cluster of worker nodes via the master. A worker node is simply a VM with some preinstalled runtimes. The master is responsible for scheduling and maintaining the cluster (amongst other things).

The simplest resource you can ask the master to provision for you is a pod.

A pod is a logical wrapper around a number of containers and in Kubernetes it is the unit of scale in a cluster.

For example, to deploy a single container to a Kubernetes stack, you would create a pod definition file (in yaml) and ask the master to provision and manage this for you, via the Kubernetes Api (kubectl).

(There is a lot of background in this post, in the next couple of posts we actually provision a number of pods and start exploring other Kubernetes resources with the goal to deploy a simple distributed containerized app - a NodeJS API with a redis cache and a mysql backend.)

Creating a cluster and installing kubectl

During this series we will start simple and gradually introduce more Kubernetes concepts and resource types as we go. To start lets get a cluster (A single master and 2 working nodes) up and running.

How much will I pay for my cluster? Well that depends on the cloud provider and specifically the size of VMs you use. You can set up a cluster for about $30 a month though on AWS/Azure and GKE.

Kubectl

Before you create your cluster install kubectl on your local machine. (I am using ubuntu)

https://kubernetes.io/docs/tasks/tools/install-kubectl/

Azure

At the time of writing Azure Container Service (AKS) is in preview. AKS is Azures newest managed Kubernetes offering. The beauty of AKS is that the master is abstracted away from you, you don't see it in your list of resources nor do you pay for it.

You can spin up a cluster in minutes. The easiest way is via the CLI (follow these instructions - https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough) This will also guide you through installing the kubectl (Kubernetes API) and linking your cluster to the API.

You can specify instance size rather than using the default:

az aks create --resource-group myresourcegroup --name mycluster --node-count 2 --generate-ssh-keys --node-vm-size Standard_B2s

You can see the list of instance sizes here:

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-general#d-series

Edit: 04/04 - You may have problems creating clusters in westeurope, try eastus instead. https://github.com/Azure/AKS/issues/280

*Edit: 09/04 - Seems to be resolved

Digital Ocean

Digital ocean do not offer a managed / one click service (at the time of writing) although Stackpoint can do all the work for you. Link your account, select your instance sizes and magically you have a cluster ready for you.

https://www.digitalocean.com/community/tutorials/webinar-series-getting-started-with-kubernetes

The alternative is to spin up CoreOS / Ubuntu boxes and installing the runtimes and link the worker nodes to the master yourself (as you would if you were installing on bare metal).

AWS

For the long time the way to set up a Kubernetes cluster on AWS was using KOPS. If you want to go down that route (it is a little more complicated than the options above) here are the instructions:

https://kubernetes.io/docs/getting-started-guides/kops/

However Amazon have recently released EKS (https://aws.amazon.com/eks/) in preview, which looks very similar to Azure's offering. Note: This is a managed Kubernetes offering not to be confused with ECS.

Look out for this when it is more widely available, currently you need to be invited to use it.

Google Container Engine (GKE)

This is possibly the easiest of the lot. Presuming you've signed up to Google Cloud (they will offer you a substantial amount of free usage) head to https://console.cloud.google.com/kubernetes.

Click 'Create cluster', pick a Zone and machine size. After clicking 'Create' you will have a fully managed Kubernetes cluster up and running.

After the cluster is created click 'Connect'. Execute the command provided on your local machine (the one with kubectl installed).

Bare metal

Setting up a kubernetes cluster on your own servers / VMs is more complicated than cloud offerings but there is some help out there for you:

https://medium.com/@sachin.arote1/installing-kubernetes-on-bare-metal-server-or-virtual-machine-via-kubeadm-8af39ec84562

https://blog.alexellis.io/kubernetes-in-10-minutes/

https://chrome.google.com/webstore/detail/sitecore-straight-to-data/lecpobmpcnpdhpljfebldoegfonlgjjj

What it does

Sitecore S2D (formerly Sitecore STD - I changed the name for obvious reasons..!) is a chrome plugin which adds a hyperlink next to various link fields in the content editor which when clicked will jump you straight to the linked item referenced within the field.

S2D works on Droplinks, Treelists and Multilists.

Simply select an option within the field (which will be another item as this plugin works with link fields) on a Multilist or Treelist and a link to the item will be rendered next to the field. Click it to go to that item (rather than Raw Values -> Copy, Search.. etc).

Droplink datasource link gets rendered automatically and will update if you change selected item.

Why chrome plugins?

The Sitecore dev's are working like crazy right now.. there is some awesome new stuff to come, but every now and then I'd like to add my own features to the content editor. Chrome plugins are a great unobtrusive way of doing this. You can get new version independent features without having to install anything on the server.

Found bugs?

I hope not.. Let me know :-)

EDIT #1 Other resources

Thanks to Dheer Rajpoot for pointing out that there is also an awesome alternative in the form of a sitecore module on the marketplace by @ISlayTians (Mr Jon Robbins) which will give you similar functionality but for more field types. If you want something fast which requires no installation on each of your sitecore instances and covers the most common link types this chrome plugin should do the job for you otherwise download Jon's module - it looks fantastic:

Get it here

There might be the situation where you have a field in use (it may have been in use for a long time) but you've realized it should be shared.

You might have different data against 50 different languages - what will happen to my data?! For example you may want the shared value to be that of the French version.

Well actually there is logic behind it and it's not based on the current language you have selected against the template.

If you make a field shared, which has data in it, Sitecore will set every language version to use the field data from the last language version you updated that field for.

Might help someone :-)

PEEK allows you to see differences in your field data for the current item across various publishing targets (i.e web/delivery db) - all from the master (content) database. It's pretty straightforward - I'll continue to update it with more features (i.e are item's children the same on web as on master.)

Why? Well I built this mainly for our content pops and QA teams who will quite often query why some content isn't displaying on the front end. In large teams working on multiple items at once it's hard to keep track of which items have been published. They (and often us investigating!) had to keep switching content databases within the CMS to check what content was indeed published.

You can get it here:

https://marketplace.sitecore.net/Modules/P/Peek.aspx?sc_lang=en

To add the new tab:

1. Install the package (there is a version for Sitecore 8 and a SPEAK 2.0 version for Sitecore 8.1)

2. Navigate to the item template _standard Values and click 'Configure->Editors' in the main ribbon. Select DEL/Peek and Save.

e.g: Sitecore.Helpers.url.getQueryParameters(window.location.href)['id']

http://mhwelander.net/2014/07/08/speak-for-newbies-part-6-speak-helpers/

I couldn't actually find the 2.0 equivilent in the documenation but actually with a quick play in the console it was pretty obvious..

Sitecore.Speak.Helpers.url.getQueryParameters(window.location.href)['id']

Mike Robbins and Martin English have a couple of great posts if you get stuck upgradeding to 2.0 and also watch this space - I'll blog anything I find!

Thinking in terms of performance we don't want poor Eric on his 320px wide Android downloading images designed for a desktop experience. This is where responsive images, the 'srcset' and 'sizes' attributes come in handy.

Specifying srcset and sizes allows the browser to determine which size image to use. We don't need to get involved at all - the browser does it all.

For example:

<img src="dave.jpg" alt="daves face" 
  srcset="dave-320.jpg 160w, dave-320.jpg 320w, dave-640.jpg 640w, dave-1280.jpg 1280w">

Using responsive images Eric only needs to download the 320px wide image to see my face rather than waiting an eternity for the 1280px full resolution version.

Browser support is pretty good too: http://caniuse.com/#feat=srcset

...and polyfills are available for those pesky older browsers: https://scottjehl.github.io/picturefill/

What about Sitecore?

Well as we know Sitecore has a pretty neat way of handling media - if you specify a ?mw= querystring you can request a lower res version of the original image.

/medialibrary/dave.ashx?mw=320

This means I don't need to crop four images in Photoshop and upload all four to my web server to achieve the example above - I just upload dave-1280.jpg to Sitecore and write my img tag thus:

<img src="dave.jpg" alt="daves face" 
  srcset="/medialibrary/dave.ashx?mw=320 160w, /medialibrary/dave.ashx?mw=320 320w, /medialibrary/dave.ashx?mw=640 640w, /medialibrary/dave.ashx?mw=1280 1280w">

Sitecore does the rest - it will serve the image at the correct resolutions and store them in media cache too!

Great!

p.s Learn more about srcset here: http://blog.cloudfour.com/responsive-images-101-part-4-srcset-width-descriptors/

p.p.s Don't use srcset without sizes: http://blog.cloudfour.com/responsive-images-101-part-5-sizes/

The idea was to build something useful and gradually add features to speed up how we use the Sitecore Content Editor. It is a chome extension so that no installaion is required within your projects, you can use it anywhere as long as you have Chrome installed! Great! Click the link above to install it. (It's worth it just for Alt+0)

New features for November

Paste to Item

This is pretty cool. have an Item Id on your system clipboard? Just press Ctrl+v (Standard paste) with the content editor open (not a focussed text box) and the item will be selected/loaded in the tree.

Go to DataSource

Within presentation details I've always wanted a Go to Datasource button. Alas we haven't got one yet but Alt+0 is the next best thing!

With the sublayout details dialog open press Alt+0. The Datasource item will load in a brand new window.

Sitecore Hotkeys is always changing and is still in BETA but it should work great. If it doesn't or you find a bug give me a shout.

What is Octopus?

If you haven't used Octopus Deploy (https://octopusdeploy.com/) I'd suggest trying it out. Octopus takes over the deploy phase your of build process. We still use Team City to build, run tests and create a package of the application (plus other bits) however it is at this point that Octopus takes over. Octopus acquires the package, runs config transforms (amongst other things) and pushes the code to target environments.

It can create IIS Sites, execute tasks on the server (via PowerShell), actually it can pretty much do everything you can think of - and most of it configurable right out of the box. The great news - it just works.

How we use Octopus

We have two main projects in Octopus, they are fairly similar. One is for one off deployments to non-production environments e.g. QA and UAT. The other is our release track - the web app is deployed to an integration environment and then promoted to live, both CM and then CD servers one at a time.

Note: Promoting a release means deploying exactly the same package to another environment ensuring consistency.

Taking the production release as an example our configuration of Octopus does the following:

1) Takes the server out of load balancer

• Runs a powershell script to take the current server out of the load balancer.
• Prompts the user to confirm the site is receiving no traffic. (This step only runs when the target server is tagged as ContentDelivery)

2) Ensures Sitecore runtimes

• Here we check if the Sitecore runtimes are on the server.
• If they are not Octopus deploys the Sitecore and Data folders. Basically everything not in source control from a nuget package we previously uploaded to Octopus.

3) Web deploy

• Acquires the latest package created by Team City.
• Run config transforms.
• Copies package contents to the server.
• Moves environment specific patch files to App_config/Include folder.
• Copies Sitecore assemblies (those not referenced by any projects but needed by the CMS to /bin)
• Deletes some unwanted files.
• Creates the application pool if it does not exist.
• Creates the IIS Site if it does not exist.
• Assigns bindings to the website.
• Notifies our team chat of success / failure.

4) Put the server back into the load balancer

• Prompt the user to confirm they have tested the deployment on the specific server.
• Runs powershell script to put the server back into the load balancer.

Below are a few screenshots with some notes if you want to see how the above is configured:

Process

Take server out of load balancer

Deploy Sitecore runtimes

In the check step we set a variable if the runtimes do not exist.

We then check this variable during the deploy runtimes phase.

Deploy web app

The pre-deplyoment script copies our environment specific config from a Configuration folder /Config/QA/Sitecore.Qa.Config to the App_Config/Include folder.

It also moves the SwitchMasterToWeb config if we are deploying to a CD box.

(This screenshot is actually from our non-prod project but the prod process is almost exactly the same.)

Final thoughts

There is so much I haven't even talked about yet - for a start how we deploy Sitecore content. I guess this is saved for another day however there is loads of good material out there for example have a Google for Sitecore.Ship / Sitecore.Octopus and also Sitecore Nirvana by the Hedgehog guys.