git local

The following alias sets up a command that displays branches where the newest commit is only in the local repository and not yet pushed to a remote:

git config --global --add alias.local "log --simplify-by-decoration --all --not --remotes --decorate --oneline"

It can subsequently be used simply like:

git local

Continuous Delivery Wishes

Dear colleague, 

Please implement the following at your nearest software development company:

Product owner:
- make stories sequentially deployable

Architecture:
- architect for continous delivery
- create small units
- let each component access only its own data and otherwise call other components' APIs
- share services/infrastructure (leads to low impact deployments)

Design:
- design for continous delivery
- make it easy to release
- make it easy to change
- make it easy to deploy
- reduce risk of deployment
- leave the system always runnable
- manage 'traffic':
-- fast lane for weekly releases
-- slow lane for less frequent releases, using feature switches and dark launches
- use feature switches
- branch by abstraction = branch in code (not in version control)

Tests:
- test for continous delivery
- create predictable tests
- run system on development environment
- acceptance-test in non-integrated environment

Development:
- integrate with main line every day

Infrastructure:
- keep short build times
- script to rebuild environment from scratch (phoenix environments)
- parallelize builds
- split builds from deployments
- use a configuration server
- use a package repository

Deployment (of code changes):
- deploy in small steps
- make non-breaking database expansions
- separate deployment from release
- use blue-green deployment
- run smoke tests
- use canary releases

Release (of a feature):
- flip a feature flag
- launch in the dark
- split test

Production feedback:
- let developers follow product into production
- monitor and study usage in production
- data mine and analyse feedback
- get real user feedback
- allow everyone fast feedback on effect of change

Process:
- deploy daily
- release when features are done
- create a 'devops' mentality
- keep the software releasable on-demand

Continuous improvement:
- remember that the delivery process is never perfect
- measure improvements
- create intermediate goals
- take small steps towards continous delivery
- automate what you're doing manually
- get measurable change fast, even if goal takes years

Possible measurements:
- how many lines of code gets deployed per week?
- how long does it take from feature development is 'dev done' to it reaches production?
- how long after deployment does it take to discover new errors?
- how many man-hours does it take to quality-assure before each deployment?
- how many man-hours does it take to sign-off each deployment?
- how many man-hours does it take to deploy per week?
- how many manual steps are involved in a deployment?

Thanks to Sam Newman, Josh Graham, Michael Nygard, Mike Brittain and Jez Humble at GOTO Århus 2012.

TortoiseGit and ssh keys

If you use TortoiseGit to access via ssh, then follow these steps to setup the 'putty key':

- Start putty key generator: C:\Program Files\TortoiseGit\bin\puttygen.exe

- Choose Load (Load an existing private key file)

- Navigate to C:\Users\\[your user name\]\.ssh

- In 'filnavn' choose id_rsa (NB! *not* id_rsa.pub)

- Choose 'Åbn' or 'Open'

- You should get a message box like 'Successfully imported foreign key (OpenSSH SSH-2 private key)...'. Press 'OK'.

- Then choose 'Save private key'

- Are you sure you want to save this key without a passphrase to protect it? Yes or No at your own decision...

- Save the file as 'C:\Users\\[your user name\]\.ssh\tortoisegit-putty.ppk'

- In tortoisegit choose Git clone

- In Url write an ssh url

- Choose load putty key and select the file you just generated 'C:\Users\\[your user name\]\.ssh\tortoisegit-putty.ppk'

Setting up NuGet for a new project

When setting up a solution to fetch from NuGet automatically:
1) Install-Package NuGetPowerTools
2) Enable-PackageRestore
4) Ignore packages folder from version control
3) Include .nuget folder in version control

More tips here:
http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html