IT training continuous delivery with windows and net khotailieu

Continuous Delivery with
Windows and .NET

Matthew Skelton and Chris O’Dell


Continuous Delivery with Windows and .NET
by Matthew Skelton and Chris O’Dell
Copyright © 2016 O’Reilly Media, Inc. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472.
O’Reilly books may be purchased for educational, business, or sales promotional use.
Online editions are also available for most titles (). For
more information, contact our corporate/institutional sales department:
800-998-9938 or

Editor: Brian Anderson
Production Editor: Kristen Brown
Copyeditor: Lindsy Gamble
Proofreader: Jasmine Kwityn
February 2016:

Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: Rebecca Demarest

First Edition

Revision History for the First Edition
2016-01-25:

First Release

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Continuous Deliv‐
ery with Windows and .NET, the cover image, and related trade dress are trademarks
of O’Reilly Media, Inc.
While the publisher and the authors have used good faith efforts to ensure that the
information and instructions contained in this work are accurate, the publisher and
the authors disclaim all responsibility for errors or omissions, including without
limitation responsibility for damages resulting from the use of or reliance on this
work. Use of the information and instructions contained in this work is at your own
risk. If any code samples or other technology this work contains or describes is sub‐
ject to open source licenses or the intellectual property rights of others, it is your
responsibility to ensure that your use thereof complies with such licenses and/or
rights.

978-1-491-94107-2
[LSI]


Table of Contents

Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
1. Introduction to Continuous Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
What Continuous Delivery Is Not
The Importance of Automation for Continuous Delivery
Why Is Continuous Delivery Needed?

Why Windows Needs Special Treatment
Terminology Used in This Book

1
3
4
4
5

2. Version Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Key Version Control Practices
Version Control Technologies
Branching Options
Use NuGet for Dependencies
Summary

7
8
11
13
14

3. Continuous Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
CI Servers for Windows and .NET
Build Automation
Integrating CI with Version Control and Ticket Tracking
Patterns for CI Across Multiple Teams
Architecture Changes for Better CI
Summary

15
22
25
25
26
26

4. Deployment Pipelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vii


Mapping Out a Deployment Pipeline
Tools for Deployment Pipelines
Deployment Techniques
Automated Testing of Database Changes
Summary

27
28
32
35
38

5. Monitoring, Metrics, and APM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Performance Counters Are Insufficient
Record Application Metrics
APM Tools Can Complement Monitoring
Aggregate Application and Windows Event Logs from All
Machines
Summary

39
39
41
43
46

6. Infrastructure Automation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Shared Versus Dedicated Infrastructure
Using a Test-First Approach to Infrastructure
Patching and OS Updates
Summary

48
49
52
53

7. The Tricky Bits of Continuous Delivery. . . . . . . . . . . . . . . . . . . . . . . . . 55
Organizational Changes
Architectural Changes (SOA/Microservices)
Operational Features
Summary

55
57
59
60

A. Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

B. Case Studies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

viii

|

Table of Contents


Foreword
Continuous Delivery is widely seen as “state of the art” in today’s
software development process. There are good reasons for this.
Continuous Delivery is grounded in a pragmatic, empirical
approach to software development. At its simplest, Continuous
Delivery is about optimizing the whole software development pro‐
cess—from having an idea to getting that idea into the hands of our
users, in the form of high-quality, working software, as quickly and
efficiently as we can. Then we can figure out what our users make of
our ideas.
We actively seek feedback loops like this within the development
process, and look to optimize them. We encourage the adoption of a
genuinely experimental approach to every aspect of software devel‐
opment. In fact, I think that over the past few years, we are seeing
signs of the software development process maturing.
I think that what we are seeing is the recognition and establishment
of what software engineering should really look like: high quality,
iterative, experimental, empirical—in fact, grounded in the scientific
method. I am probably biased, but I believe that Continuous Deliv‐
ery represents an important step forward in the software develop‐
ment process. It works. It makes the organizations that practice it

more efficient at creating high-quality software that delights their
users.
You will notice that my description did not mention technology at
all. That is because the ideas of Continuous Delivery are not tied to
any specific technology. You can practice this approach to develop‐
ment for any software tech. However, if our aim is to “create a
repeatable, reliable process for software delivery,” then automation
plays an important part. After all, human beings are not really very
good at being repeatable and reliable! So technology, though not the
most important aspect, plays a vital role. On this technology front,
the picture across the software industry is complex. There are at
least two factions: the world of Windows and .NET, and the Unixbased tribes of the “Open Stack.”
I think it fair to say that some of the initial innovation in the Contin‐
uous Delivery space came from the Open Stack community—unit
test frameworks, build management systems, sophisticated version


control and dependency management systems, and more recently
support for ideas like “infrastructure as code” and “deployment
pipelines.”
It has never been as simple as “Open Stack has the best tools and
Windows plays catch-up.” The first publicly available Continuous
Integration (build management) system was CruiseControl, fol‐
lowed quite quickly by a “port” to Windows called CruiseCon‐
trol.NET, which was significantly better than the original. So over
time, both worlds have developed their own collections of technol‐
ogy to support Continuous Delivery and its associated practices.
Because many of the people that started the conversation on this
new approach came from the Open Stack world (myself included),
the language that we used and the tools that we described were not

always descriptions or technologies that would resonate with some‐
one from the Windows and .NET world.
It is great to see Matthew and Chris redress the balance. This book is
much more than a simple description of Windows native tooling for
Continuous Delivery, though that information is provided here.
This book explores the ideas of Continuous Delivery and talks about
the broad concepts and philosophy, as well as describing some of the
specific tooling that works in a Windows-native way. In addition, it
also describes some of the tools that are stack-neutral and available
to any software developer whatever their toolset.
Chris and Matthew bring real-world experience to their writing, and
back up their descriptions with firsthand experience of the technol‐
ogies described and case studies from many different organizations.
If you are developing software of any kind in the Windows environ‐
ment, this book is for you. Continuous Delivery is too important an
idea to miss the boat. Enjoy the book!
—Dave Farley
Independent consultant and
coauthor of
Continuous Delivery


Preface

By re-architecting for Continuous Delivery, and using tools like Chef
and GoCD in combination with Windows and .NET, we were able to
move from infrequent, difficult code deployments to weekly, daily, and
even hourly deployments, whilst improving our availability and mean
time to recovery.
—John Esser, Ancestry.com

Continuous Delivery is a well-defined set of practices and
approaches to releasing software in a reliable way. At the heart of
Continuous Delivery is the automation of software builds, software
testing, and software deployments, including the automated config‐
uration of devices and environments for testing and runtime.
Organizations increasingly rely on software systems to enable and
power their services, sales, or operations (or all three), and so fre‐
quent, reliable, repeatable, and rapid releases are essential in order
to keep pace with demands for change. The practices that form
Continuous Delivery are no longer optional for many organizations,
but rather central to their very survival.
Today, all core software from Microsoft is PowerShell-scriptable,
and teams working with Windows and .NET in 2016 and beyond
are able to use a rich set of PowerShell and HTTP REST APIs in
software packages and products from Microsoft, third-party ven‐
dors, and the open source community. This ability to automate
Windows and .NET is a huge enabler for Continuous Delivery.
Many of the technologies and approaches for Continuous Delivery
are essentially identical across different operating systems, but some
things need special treatment for Windows and .NET. When Jez
Humble and Dave Farley published their groundbreaking book,
xi


Continuous Delivery [HumbleFarley], in 2010, many of the tools
described were either nonexistent on the Windows platform or did
not support the rich automation capabilities they do now. Our book
acts as an addendum to Jez and Dave’s book to encourage many
more teams working with Windows and .NET to adopt Continuous

Delivery.

Who Should Read This Book
If you build, release, or operate software systems built on .NET or
Windows, then this book is for you. Architects, product managers,
and CxOs in your organization should read Chapter 7, The Tricky
Bits of Continuous Delivery, and start planning some significant
changes.

Product Development Best Practices
While good practices for product development with software, such
as User Stories, are beyond the scope of this book, we refer to them
occasionally. See the excellent book Implementing Lean Software
Development [Poppendieck] for more details.

The Structure of the Book
A successful adoption of Continuous Delivery is built upon solid
foundations of technical excellence, which we describe here:
Version control, branching, and merging (Chapter 2)
Everything in Continuous Delivery flows from sound version
control.
Continuous Integration done well (Chapter 3)
Without CI for application and infrastructure code, Continuous
Delivery is not possible.
Deployment pipelines (Chapter 4)
These are for deployment coordination, sharing information,
and continuous improvement.
Infrastructure automation (Chapter 6)
Well-tested, well-structured code that defines servers and envi‐
ronments is needed.

xii

| Preface


The tricky bits (Chapter 7)
These things are as important as the more technical bits, but
often get forgotten.
Many teams working with Windows/.NET have been slow to adopt
modern, scriptable tools like NuGet and Chocolatey (package man‐
agement), DSC/Chef/Puppet/Ansible (configuration management),
and Vagrant/Packer/ServerSpec (server testing). We have tried to
provide a flavor of the kinds of tools you should expect to use, the
challenges you might face, and enough understanding of the princi‐
ples to go and explore the tools and techniques for yourself.
In summary, enjoy the automation that modern Windows and .NET
tools and software offer, but don’t forget the social, architectural,
and operational challenges that Continuous Delivery requires. We
assure you that the changes will be worth it in the end!
In this book, we use C# (so project files are .csproj) but
most of the advice applies equally well to other .NET
languages like VB.NET or F#.

We hope you find this book useful. We’d love to receive your feed‐
back—send us an email at or leave a com‐
ment on the book’s website: />
Acknowledgments
We’d like to thank several people for their comments and support:
first, all the people and organizations featured in the case study

examples (Andy Lole at Carnect, Paul Shannon at 7digital, Steve
Elliott at LateRooms.com, Peter Mounce at JUST EAT, Owain Perry
at JustGiving, and John Esser and Russ Barnet at Ancestry.com).
Second, we’d like to thank our technical reviewers for their insights
(Josef Sin, John Adams, Colin Beales, and Giles Davies from the Vis‐
ual Studio UK team, and Kundana Palagiri and colleagues from the
Microsoft Azure team). Third, we’re grateful to colleagues and
friends who made suggestions, including Matt Richardson, Rob
Thatcher, João Lebre, and Suzy Beck. Finally, we’d like to thank Dave
Farley for writing the Foreword, and the editorial team at O’Reilly
(including Brian Anderson and Kristen Brown) for asking us to
write this book in the first place and making it ready for publication.

Preface

|

xiii



CHAPTER 1

Introduction to Continuous
Delivery

Continuous Delivery is one of the most valuable approaches to soft‐
ware development to emerge in recent years. At its core, Continuous
Delivery is a set of practices and disciplines that enable organiza‐
tions to reach and maintain a high-speed, predictable, steady, and

safe stream of valuable software changes irrespective of the kind of
software being developed. Continuous Delivery works not just for
web-based software, but also mobile apps, on-premise hosted desk‐
top software, device firmware, and so on.
In 2010, Jez Humble and Dave Farley wrote the book Continuous
Delivery [HumbleFarley] based on their experiences building and
releasing software for clients around the world. Their book is a
hugely valuable collection of techniques, advice, and suggestions for
software delivery and provides the de facto definition of Continuous
Delivery.

What Continuous Delivery Is Not
Many people confuse Continuous Delivery with Continuous
Deployment, but the two are quite different in purpose and execu‐
tion. As seen in Figure 1-1, Continuous Delivery aims to enable reg‐
ular, rapid, reliable software releases through a set of sound practi‐
ces, giving the people who “own” the software product the power to
decide when to release changes. Continuous Delivery is a so-called
pull-based approach, because software is “pulled” through the deliv‐
1


ery mechanism when needed, and applies to all kinds of software
(web, desktop, embedded, etc.).

Figure 1-1. Continuous Delivery feedback
In contrast, as shown in Figure 1-2, Continuous Deployment is a
push-based approach: when software developers commit a new fea‐
ture to version control, it is pushed toward the Live systems auto‐
matically after successfully passing through a series of automated

tests and checks. This results in many Production deployments a
day.

Figure 1-2. Continuous Deployment feedback
From our experience, Continuous Deployment is a niche practice
useful for web-based systems in small, highly focused development

2

|

Chapter 1: Introduction to Continuous Delivery


teams. Continuous Delivery suits a much wider range of software
scenarios and is a much more effective approach with management:
“we’re giving you the power to choose when to release new features”
is quite an eye-opener for many in senior management!

The Importance of Automation for Continuous
Delivery
In Continuous Delivery, we aim to automate all the repetitive, errorprone activities that humans do that can lead to inconsistent, unreli‐
able, or unrepeatable processes and outputs:
• Software compilation and unit testing (“builds”)
• Software testing (component, service, integration, and UI)
• Deployment of software and infrastructure through all environ‐
ments, including Production
• Configuration of applications and infrastructure (including net‐
works, DNS, virtual machines [VMs], and load balancers)
• Database changes (reference data, schema changes, and data

migrations)
• Approval of everyday IT changes (“standard changes”)
• The tracking and tracing of change history and authorizations
• Testing of Production systems
We use the word “Production” to refer to the environ‐
ment where your software is serving customers. This is
sometimes called “Live,” but we feel this is a loaded
term likely to cause confusion.

These are all areas where we can get computers to do a much better
job than humans: more consistent, more repeatable, more reliable.
Areas that we leave for human input are limited to those areas where
humans add a huge amount of value: software development itself,
test strategy and approaches, exploratory testing [Hendrickson],
performance test analysis, and deployment and rollback decisions.

The Importance of Automation for Continuous Delivery

|

3


Why Is Continuous Delivery Needed?
Developing and operating modern software successfully requires a
combination of good tools, well-trained and well-socialized people,
good team discipline, a clear and shared purpose, and well-aligned
financial and organizational goals. Too many organizations believe
that they can do without one or more of these ingredients, but the
result is that software is expensive, late, or faulty, and often all three.

By adopting Continuous Delivery, organizations can lay the founda‐
tions for highly effective software delivery and operations, consis‐
tently producing high-quality software that works well in Produc‐
tion and delights clients and customers.

Why Windows Needs Special Treatment
Many of the tools commonly used for Continuous Delivery are not
available natively for the Windows platform, so we need to find
Windows-native approaches that achieve the same ends.
In particular, package management (in the form of NuGet and
Chocolatey) has only been available on the Windows platform since
2010, whereas operating systems such as Linux and BSD (and more
recently Mac) have used package management for software distribu‐
tion and installation since at least 1997. Other good approaches
being adopted on Windows are:
• Plain text files for configuration of applications and services
(rather than the Windows Registry or databases)
• Controlling application behavior from the command line (rather
than a GUI)
• A multivendor, open source–friendly approach to software in the
Windows ecosystem
• Easily scriptable package management with declarative depen‐
dencies
Many of the new and forthcoming features in Windows Server 2016
and Visual Studio 2015/Visual Studio Online (VSO) are designed
with Continuous Delivery in mind.

4

|

Chapter 1: Introduction to Continuous Delivery


PowerShell provides a command-line interface to Win‐
dows for controlling application and system behavior
and configuration. As a result, PowerShell is now the
primary means of automating Windows components
and .NET software.

The tips and advice in this book will help you navigate the route to
Continuous Delivery on the Windows/.NET platform. Real-world
case studies with Windows/.NET software show that successful
companies around the world are using the techniques.

Terminology Used in This Book
We’ll use these terms throughout the book:
Artifact
Immutable, versioned files or collections of files that are used
for deployments
Continuous Delivery (CD)
Reliable software releases through build, test, and deployment
automation
Continuous Integration (CI)
Integrating work from developers as soon as possible, many
times a day
Cycle time
The time spent by the team working on an item until the item is
delivered (in a Continuous Delivery context)
DBA

Database administrator
DSC
Desired State Configuration
DSL
IIS

Domain-specific language
Internet Information Services

Terminology Used in This Book

|

5


Infrastructure
Servers, networks, storage, DNS, virtualization—things that
support the platform
Infrastructure configuration management (or just config manage‐
ment)
See Infrastructure as code
Infrastructure as code
Treating infrastructure as if it were software, and using software
development techniques (such as test-driven development)
when developing infrastructure code
LDAP
Lightweight Directory Access Protocol
On-premise
Self-hosted systems, managed internally by the organization—

the opposite of SaaS-hosted systems
Package management
Software and established practices for dependency management
via named collections of files with specific version numbers
Production
The environment where the software runs and serves custom‐
ers, also known as Live
SCCM
System Center Configuration Manager
Software-as-a-Service (SaaS)
Hosted software services—the opposite of on-premise or selfhosted systems
SysAdmin
System administrator
Test-driven development (TDD)
Evolving software in a safe, stepwise way, emphasizing main‐
tainability and clarity of purpose
User interface (UI)
Also known as graphical user interface (GUI)
Version control system (VCS)
Sometimes called source code control or revision control
6

|

Chapter 1: Introduction to Continuous Delivery


CHAPTER 2

Version Control

Controlling versions of text files (code, configuration, static data,
etc.) is a crucial facet of Continuous Delivery. Version control pro‐
vides traceability, predictability, and repeatability, because we’re
forced to treat the version control system as the definitive source of
truth. Version control is also a central communication mechanism
between teams and team members, indicating the intent and pur‐
pose of our changes so that people can make better decisions.

Key Version Control Practices
Some important principles for version control in a Continuous
Delivery context are:
• Commits to version control should be cohesive and meaningful,
helping people to see why a change was made.
• Commits should happen many times per day—if your version
control system or practices work against multiple daily com‐
mits, you’re likely using the wrong approach.
• Branch as little as possible (see “Branching Options” on page
11)—use techniques such as feature toggles to manage partially
completed work. Focus on completing a small number of
changes rather than tackling many things in parallel.
• Any non-trunk branches should be short-lived—especially fea‐
ture branches.

7


Furthermore, for Continuous Delivery, we tend to prefer many
smaller repositories to one large repository, using package manage‐
ment to bring together dependent modules (see “Use NuGet to

Manage Internal Dependencies” on page 14).

Carnect: Version Control Changes for
Continuous Delivery
Carnect is a leading car rental booking engine and solutions pro‐
vider working worldwide with a portfolio of over 500 car rental
suppliers. Founded in Hamburg in 1999 as MicronNexus GmbH,
Carnect in 2007 joined TUI Group, the largest leisure, travel, and
tourism company in the world.
Carnect provides digital content via white-label websites and vehi‐
cle booking services via web APIs; their systems run on the Win‐
dows platform using a mixture of VB.NET and C# components.
The Carnect teams began adopting elements of Continuous Deliv‐
ery in early 2015, with a focus on build automation, automated
tests, and repeatable deployments.
Andy Lole, CTO at Carnect, explains that:
The combination of .NET on Windows and tools like GitHub,
JIRA, and TeamCity works really well for us. The tech teams at
Carnect love the development speed and power of .NET, but
using TFS for version control was really hurting our ability to
release in a controlled and repeatable manner. By moving our
code to GitHub and wiring it up to JIRA and TeamCity we can
safely run much faster and more consistently than before.

The need to trace a change from version control through a build to
a deployed package was a big factor in adopting newer practices,
and this new ability has helped the teams to track down within
minutes problems that used to take days to resolve.

Version Control Technologies

In 2015 and beyond, you should choose or switch to a hosted (SaaS)
version control solution unless you have a very clear understanding
of why you need a self-hosted (on-premise) tool. Only those organi‐
zations with an excellent capability in infrastructure and security
management should consider on-premise version control. If you’re
certain that self-hosted/on-premise is right for you, then good
8

|

Chapter 2: Version Control


options are GitHub Enterprise, Bitbucket Server (formerly Stash),
and RhodeCode.
The most effective SaaS version control providers for Windows
and .NET software include:
• GitHub
• Bitbucket
• Visual Studio Online
• CodebaseHQ
• CloudForge
The SaaS hosting solution acts as the definitive central location for
code integration and collaboration.
Modern SaaS version control tools provide enterpriselevel features such as integration with LDAP and finegrained security permissions control, along with pri‐
vate repositories. Using a SaaS provider does not mean
that your files need to be open sourced.

You will also need client tools to run on each workstation, build
agent, or server. Client tools are generally free of charge.

Git
Git is currently the de facto standard for version control and is a
powerful, safe, and flexible version control tool. You should choose a
Git-based solution for Continuous Delivery with Windows
and .NET unless you have a good reason to use a different tool, and
invest in Git training for everyone using version control, including
SysAdmins and DBAs.
Free client tools for Git on Windows include:
Git for Windows (or git bash)
Good for cross-platform work
GitHub for Windows
A GUI tool from GitHub
Atlassian SourceTree
Rich GUI tool for beginners and experts
Version Control Technologies

|

9


POSH-git
PowerShell environment for Git
Git Extensions
Git integration for Visual Studio
TFS 2013 or later
(Using the Git option for version control)
In practice, if you choose to use Git, you will need a hosted solution
such as GitHub, Bitbucket, or Visual Studio Online.

Mercurial
Mercurial is similar to Git. Some Windows and .NET-based tools
support Mercurial, but with the popularity of Git and GitHub, along
with Git’s superior branch handling, it’s unlikely that Mercurial will
provide much benefit over Git for most teams.
If you need to use Mercurial on Windows, one of the best client
tools is currently Atlassian SourceTree. SourceTree is a free down‐
load and supports Git as well as Mercurial.

Subversion
Subversion is a well-established version control system that can
work well for small- to medium-sized repositories in a Continuous
Delivery context. Subversion uses a central server for the definitive
repository copy along with operations such as svn log for seeing
history. This means that some operations (particularly viewing the
log) are slow compared to similar operations in Git or Mercurial.
Compelling reasons to use Subversion include TortoiseSVN, which
provides rich integration with the Windows Explorer shell, and Sub‐
version’s native support for binary files, making updates and fresh
checkouts (for CI) much quicker than with Git for large numbers of
binary files.

TFS
Until the release of Team Foundation Server (TFS) 2013, the Team
Foundation Version Control (TFVC) component of TFS alone pro‐
vided version control features using a central server. The early ver‐
sions of TFS/TFVC (2005, 2008, 2010, and 2012) possessed several

10

| Chapter 2: Version Control


features of Microsoft’s legacy Visual Source Safe VCS that were
incompatible with Continuous Delivery [Hammer].
However, TFS 2013 added support for Git repositories, thereby
combining the richness of Visual Studio with the flexibility and
power of Git. Future versions of TFS and Visual Studio Online will
provide support for accessing Git repositories over SSH (currently,
only Git over HTTPS is supported). With TFS 2015 there is also
expanded support for the cloud-based Visual Studio Online, inte‐
gration with Azure, and native integration with GitHub.
With strong support for Git, as well as programmability via REST
APIs and agile-oriented features, TFS 2015 promises to be a much
better fit for Continuous Delivery than previous versions.

Branching Options
A developer has a problem to fix, so they create a feature branch. Now
they have two problems to fix.
—Anon.

Modern version control systems allow for branching of the source
code, thereby allowing for multiple parallel streams of work on the
same project. This is an alluring prospect that gives the illusion that
multiple development streams can be achieved on the same code‐
base without impacting one another. Unfortunately, this method is
fraught with issues when the time comes to bring these parallel
streams back together.
Where possible, avoid many long-lived branches, preferring instead

either trunk-based development or short-lived feature branches.
Trunk-based development is the practice of making changes directly
onto the trunk or master branch without feature branches. This
practice requires a discipline in the developers to ensure that the
HEAD of the trunk is always in a releasable state; a stepping-stone
toward trunk-based development is GitHub Flow, the practice of
using pull requests.

Branching Options

|

11


Do not be tempted to rush into branching just because
your version control tool has good branching support.
Git in particular supports branching well, but Git was
designed for collaboration on the Linux kernel code by
geographically separated individuals. Your software
teams (should) have much better communication than
the Linux kernel team, so give preference to communi‐
cation instead of branching!

Pull Requests
Pull requests, or merge requests, are becoming a popular way to
manage development. They work in a similar way to feature
branches, although on a much smaller scale.
The developer works on a local clone of the codebase, making a
small change that is pushed to her centrally hosted clone. Then,

using the hosted tool, GitHub, Bitbucket Server (formerly Stash), or
something similar, the developer makes a request to the owners of
the origin repository to review and merge the change.
The process stems from open source development where developers
are spread out throughout the world and in various time zones. It
allows for the owners to review and judge each request as to whether
it is suitable for merging. For this scenario it is perfect, although in
larger organizations it can make the flow of changes quite stilted.
The GitFlow model for development work with Git is
popular but in our view can lead to situations where CI
happens less frequently than with other branching
models. GitFlow also has a steep learning curve for
people new to version control. We recommend that
you explore other models before trying GitFlow.

Feature Toggles
Large features and changes are always needed. We can decompose
the work to be as small as possible, yet there will be times when they
are part of something larger that can only work together once fully
implemented. This can still be achieved in trunk-based development
by employing Feature Toggles.
Feature Toggles, at their simplest, can merely be if statements sur‐
rounding the usage of your new functionality. They could also be
12

|

Chapter 2: Version Control

implemented through factory methods or instantiating different
implementations via IoC. The scope and complexity of the toggle
depends on what your feature change is.
For further reading on branching strategies, look up
Steve Smith’s excellent blog series on Version Control
Strategies.

Use NuGet for Dependencies
NuGet is the open source dependency package management tool
for .NET. NuGet is distributed as a Visual Studio Extension and is
preinstalled by default in Visual Studio version 2012 and later.
NuGet can also be used from the command line, which is useful for
automated scripting. The NuGet client tools provide the ability to
both produce and consume packages. NuGet Gallery is the central
package repository used by open source package authors and con‐
sumers.
NuGet is similar in its goals to package managers used in other lan‐
guages, such as Java’s Maven, Ruby’s Gems, and Node’s NPM. It pro‐
vides a way to specify a package for installation and along with it
installs that package’s dependencies at the required versions.
As seen in Figure 2-1, the NuGet Visual Studio Extension provides a
GUI for finding and installing packages from the NuGet Gallery.

Figure 2-1. The NuGet Visual Studio Interface
The following sections cover some good practices for working with
packages and package management.
Use NuGet for Dependencies

|

13