Monthly Archives: June 2017

Why Continous Delivery is vital in the Enterprise

When reviewing the DevOps study of last years I noticed an interesting slide depicting the number of deployments per day per developer.  This go against my personal experience that when projects are late adding developers to a project can decrease the overall productivity of the team.  The general rule is that when growing software and development teams you decrease the individual productivity of each developer.  This is mainly due to communication and integration overheads.

The DevOps study of 2015 found that for the high performers, those who continuously integrate and deploy code to production this rule does not apply.  The study demonstrates that organizations that do not practice continuous delivery deploy with decreasing frequency but that those that have adopt these practices deploy significantly increasing frequency.

This demonstrates that practicing continuous delivery is especially important for large enterprises. By adopting these practices they can compensate for the overhead linked with large systems and actually increase the productivity of large development teams.

Embrace Continuous Delivery or die!

In the classical view of software delivery, you need to make a trade-off between quality and speed. The traditional IT delivery process paradigm postulate that building quality software will demand longer to deliver. You trade quality with getting things done rapidly. Now, studies on teams that have adopted Continuous Delivery (CD) demonstrate exactly the opposite. Teams able to deploy by the push of a button not only deliver faster but they deliver better quality in a more reliable way. Being able to push changes fast and reliably to production changes the rule of the game and transforms many aspects of the IT delivery process. It reflects on aspects like:

Increased Availability & Manageability

Because you can push changes a lot faster you can make smaller changes with less downtime you don’t need to come in the middle of the night or weekends to deploy the system. This means less overwork and stress. It also frees up a considerable amount of time as teams don’t need to participate at long lasting release planning’s sessions to coordinate huge deployments.

Because you know you can push a change fast you’re also able to re-mediate faster and you don’t need to take account of being able to reverse a giant change. In place, you can adopt release strategies where you always advance forwards. In place of reverting a change you can be confident that you can fix any problem fast. This simplify the release process and lower the architecture complexity needed to be able to revert back a giant change.

Reports also demonstrates that teams practicing CD sees their number of big incidents diminishing drastically. Apart from the better intrinsic quality that CD brings this is also due to the automation that CD demands. The automated deployment pipeline eliminates errors that might result from manual configuration and error-prone practices.

Increased efficiency and shorter cycle time

Because you make smaller changes your tester and analyst can work in a constant flow of work. They don’t need to test everything in a great batch at the end of the release but can continuously work in at constant pace together with the developers.

When practicing continuous delivery automated tests are run immediately after each check-in what detects many bugs immediately. Bugs that are detected sooner are cheaper to fix. The developer can get immediate feedback even before he starts working on another task and so he knows where to search for the bug. It’s proved by many studies that bugs found before or immediately after the check-in are orders in magnitude cheaper to fix (sometimes more than 100 times).

Improved testability

To be able to deploy small changes independently the systems needs to be decoupled. This decoupling enables also to test the system more easily in isolation. Most of the changes can be tested without deploying to an integration environment. This lowers the number of environment needed and allows for a more rapid feedback.

Improved intrinsic product quality

Because the tremendous acceleration of time to market of a change, from once every 3 months to many times a day, product owners can experiment a lot faster enabling new product evolution strategies based on experimentation and continuous improvement. The book Lean Enterprise describes in detail how modern software companies takes advantages of continuous delivery to design products based on experimentation.

Improved Customer Satisfaction

CD brings confidence to the customers and other stakeholders on the delivery of their new features. CD enables to deliver new features at a constant and predictable pace and increase the visibility of the delivery process. By practicing feature toggles and decoupling the deployment from the actual release of the feature it enables to deploy a part or a complete new capability to early adopters.

Organizations that are more effective can spend more time on value adding activities. This creates a virtuous circle of continuous improvements that brings a decisive competitive advantage. Continuous Delivery is becoming the norm in the enterprise. IT organization that still stick to the old delivery model will be forced to change or will simply disappear. Following the 2015 State of DevOps practices study, the companies who their IT team’s practices continuous delivery has 50 % higher market capitalization growth over the 3 last years than the other and Gartner predicts that by 2020 50% of CIO’s that have not transformed their capabilities will be displaced.

Tutorial: How to use Angular CLI with DotNetCore

In this post we’ll explore how to use the Angular CLI to build an application hosted inside a DotNetCore.1.1 web api project. The code that accompanies this post can be found here.

1.      Create a new WebApi application

Open a command line and use the following commands to generate your WebApi project.

mkdir AngularDotNetCore
cd .\AngularDotNetCore\
dotnet new webapi

2.     Configure the WebApi project for Angular

    1. Open the project with Vs Code and edit the .csproj
    2. Disable the automated compilation of typescript as it will be handled by the Angular-cli (line 4)
    3. Add a reference to the Microsoft.AspNetCore.StaticFiles package so that we’ll be able to serve static files from the “/wwwroot” (line 13)
<Project Sdk="Microsoft.NET.Sdk.Web">

    <Folder Include="wwwroot\" />

    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.2" />
   <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="1.0.0" />

c. To install the new packages run:

dotnet restore

3. Modify Startup.cs

  1. Redirect all non API requests to the index.html page. (line 6-14)
  2. Configure the app to serve static files and use the index.html as default page. (line 17-23)
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)

    app.Use(async (context, next)=&amp;amp;amp;amp;gt;{
        await next();
        if (context.Response.StatusCode == 404 &amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;
            !System.IO.Path.HasExtension(context.Request.Path.Value) &amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;
                context.Request.Path = "/index.html";
                await next();

    // use default route /api/[controller] 

    // use index.html as default page
    // serve static pages

3. Initialize the Angular App through Angular-CLI

  1. a. Install Angular-CLI
    npm install @angular/cli --global
  2. b. Create the Angular app
    ng new my-app --skip-install
  3. c. Move to the root all the content of your “my-app” folder
    mv .\my-app\* .\
  4. d. Delete the “my-app” folder:
  5. e. Define the “wwwroot” as the Angular-CLI output directory.
    Edit the .angular-cli.json and update the “apps” part (line 9):

      "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
      "project": {
        "name": "my-app"
    "apps": [
        "root": "src",
        "outDir": "wwwroot",
        "assets": [
        "index": "index.html",
        "main": "main.ts",
        "polyfills": "polyfills.ts",
        "test": "test.ts",
        "tsconfig": "",
        "testTsconfig": "tsconfig.spec.json",
        "prefix": "app",
        "styles": [
        "scripts": [],
        "environmentSource": "environments/environment.ts",
        "environments": {
          "dev": "environments/environment.ts",
          "prod": "environments/"
      "e2e": {
        "protractor": {
          "config": "./protractor.conf.js"
      "lint": [
          "project": "src/"
          "project": "src/tsconfig.spec.json"
          "project": "e2e/tsconfig.e2e.json"
      "test": {
        "karma": {
          "config": "./karma.conf.js"
      "defaults": {
        "styleExt": "css",
        "component": {}
  6. f. Install the npm packages
    npm install
  7. g. Build and run the app
    ng build
    dotnet run
  8. If everything went fine you should see:

4. Call from Angular the WebApi backend

Here we’ll make a simple http call from our Angular application to our DotNetCore Web Api. We’ll query the generated example “ValuesController” from our Angular app and output the result onto our homepage. Because I want to make this example as simple as possible I make the call directly from the component but in a real application you’ll encapsulate this code into an Angular service.

  1. a. Edit the app.component.ts file:
    import { Component, OnInit } from '@angular/core';
    import { Http } from '@angular/http'
       selector: 'app-root',
       templateUrl: './app.component.html',
       styleUrls: ['./app.component.css']
    export class AppComponent implements OnInit {
       constructor(private _httpService: Http) { }
       title = 'app works!';
       values:string[] = [];
       ngOnInit() {
          this._httpService.get('/api/values').subscribe(values => {
             this.values = values.json() as string[];
  2. b. Edit the app.component.html file:
      Retrieved values:
    <ul *ngFor="let value of values">
  3. c. Compile and run the app:
    ng build
    dotnet run

5. Configure your Angular application to auto update when code changes

The Angular-CLI can configure webpack to serve the application through his built-in server and refresh your page whenever a file changes. To launch this developer friendly mode use:

ng serve

Notice that when you open your browser on http://localhost:4200 (the webpack server default port) you don’t see any retrieved values anymore.

This is because our Angular application calls our REST API on http://localhost:4200/api/values but there’s nothing there! What we need to do is launch our WebApi application and redirect calls to it from port 4200.

  1. a. Create a “proxy.json” file on the root and add the following content to the file:
       "/api": {
          "target": "http://localhost:5000",
          "secure": false
  2. b. Launch two consoles. One to run the webapi app:
    dotnet run

    The other to launch the webpack server with the proxy redirection:

    ng serve –proxy proxy.json
  3. c. You can also enable the auto refresh mode of your WebApi application. Edit the .csproj file and add following section and run “dotnet restore”:
       <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="1.0.0" />
  4. d. Now you can launch also the WebApi in watch mode:
    dotnet watch run 

Of course, you’ll still need to refresh your page every time you change your webapi project but it will recompile & run automatically every time code is changed.

Have fun!