Release with Git - Patrick

From Training Material
Jump to navigation Jump to search

Release Management & Deployment Using Git
Patrick Mazzotta

About Us ⌘


  • Training & Consultancy Provider
  • Founded in 2005
  • Currently offering over 400 courses (remote & on-site)
  • Continuously exapnding through franchishing opportunities

About Me ⌘


  • Consulting in IT & BI for 20 years
  • CEO & Co-Founder of Craedone
    • Analytics
    • Business Intelligence
    • Corporate Strategy/Red Team services
  • Partnered with NobleProg since 2013

Expectations ⌘

  • customization vs. course standards
    • content
    • ugly slides (content > appearance)
  • Dialogue - me vs. reading a book

(hint: I'm not a very good book!)


  • Project management guides & influences release management

There have been several attempts to develop project management standards, such as:

  1. ISO/IEC/IEEE 16326-2009 - Systems and Software Engineering--Life Cycle Processes--Project Management. December 2009. DOI: 10.1109/IEEESTD.2009.5372630. ISBN 978-0-7381-6116-7
  2. Body of Knowledge 5th edition, Association for Project Management, 2006, ISBN 1-903494-13-3

Project Management Standards (1 of 300)⌘


Just kidding! (... kind of)

PM boiled down⌘

PM practices loosely fall under two main categories:

  1. Waterfall Waterfall.gif
  2. Agile AgileDance.gif


Great when:

  • you are subcontracting (esp. in manufacturing)
  • you have feature (or specification) -based constraints

Sub-optimal when:

  • you need fixed or predictable timeframes
  • projects become large and/or complex



Great when:

  • you need to get "something" out quickly and can make iterative improvements
  • when you have lots of contact points between interdependent teams

Sub-optimal when:

  • teams have broken or intermittent communication
  • your project exists in highly politicized environments


Agile Manifesto⌘

"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The Many Faces of Agile⌘


Leading Methodologies⌘

  1. Scrum Agile-SCRUM.png
  2. Kanban Simple-kanban-board-.jpg

Scrum vs. Kanban: Similarities⌘

- Lean and Agile - use pull scheduling - limit WIP (work in progress) - use transparency to drive process improvement - focus on delivering releasable software early and often - based on self-organizing teams - require breaking the work into smaller pieces - continuously optimize release plans based on empirical data (velocity/lead time)

Scrum vs. Kanban: Differences⌘

Scrum Kanban
Timeboxed iterations prescribed. Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed.
Team commits to a specific amount of work for this iteration. Commitment optional.
Uses Velocity as default metric for planning and process improvement. Uses Lead time as default metric for planning and process improvement.
Cross-functional teams prescribed Cross-functional teams optional. Specialist teams allowed.
Items must be broken down so they can be completed within 1 sprint. No particular item size is prescribed.
Burndown chart prescribed No particular type of diagram is prescribed
WIP limited indirectly (per sprint) WIP limited directly (per workflow state)
Estimation prescribed Estimation optional
Cannot add items to ongoing iteration Can add new items whenever capacity is available
A sprint backlog is owned by one specific team A kanban board may be shared by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles
A Scrum board is reset between each sprint A kanban board is persistent
Prescribes a prioritized product backlog Prioritization is optional


  1. Kanban vs. Scrum, PDF reference.

So Now What?⌘

The objective of Release and Deployment Management is to ensure that:

  1. There are clear and comprehensive release and deployment plans that enable the customer and business change projects to align their activities with these plans
  2. A release package can be built, installed, tested and deployed efficiently to a deployment group or target environment successfully and on schedule
  3. A new or changed service and its enabling systems, technology and organization are capable of delivering the agreed service requirements, i.e. utilities, warranties and service levels
  4. There is minimal unpredicted impact on the production services, operations and support organization
  5. Customers, users and Service Management staff are satisfied with the Service Transition practices and outputs, e.g. user documentation and training.

The "why" behind these objectives:

  1. clear plans are easy to reproduce (and script!)
  2. efficiency and predictability allows for more repliable planning (see #1)
  3. especially important for cost and risk analysis, but also provides scope to expectations
  4. the more thorough your replease plans and processes are, the faster and easier you can track down bugs and predict points of failure (scaling up)
  5. especially practical for onboarding new team members and knowledge transfer in general

Automation vs manual⌘

Whether by automation or other means, the mechanisms to release and deploy the correctly configured service components should be established in the release design phase and tested in the build and test stages.

Automation will help to ensure repeatability and consistency. The time required to provide a well-designed and efficient automated mechanism may not always be available. If a manual mechanism is used it is important to monitor and measure the impact of repeated manual activities as they are likely to be inefficient and error-prone. Too many manual activities will slow down the release team.

Many of the release and deployment activities can be automated. For example:

  1. Discovery and installation software can check whether the required prerequisites and co-requisites are in place before installation of new or changed software components.
  2. Automated builds can significantly reduce build times that in turn can resolve conflicts and delays.
  3. Automated configuration baseline procedures save time and reduce errors in capturing the status of configurations and releases during build, test and deployment.
  4. Automatic comparisons of the actual live configuration with the expected configuration help to identify issues at the earliest stage.

Automatic Deployment via Git⌘

The ultra-thin summary:

  • have Git spread liberally throughout the stack
  • make sure the team is sharing communications with Jenkins
  • pick a scripting solution and be prepared to stick with it for a while
  • prepare your configs with Puppet or Ansible
  • eventually, model your own systems using Docker, and wire it into your CI flow

The Prod Repo⌘

  • keep it in a clean state at all times
  • tags, tags, tags, and more tags (only tags!)
  • structure of the repo matters (especially with submodules and subtrees)

Release Branches⌘

Recap from Git course:

  • multiple teams/tasks means frequent merges to keep things fresh
  • cut release branches from Master
  • avoid squashing
  • release branches are not permanent!

Git central repository model diagram.png

Using tags⌘

  • only tag at the completion of a full test cycle (don't tag candidates)
  • use consistant naming
  • be smart about tag descriptions (be consistant)


Switching Between Releases⌘

  • be systematic (programmatic!)
  • never veer from tags

Maintenance & Releases⌘

There are two approaches to maintenance

  1. maintenance-as-a-feature
    • fixes and updates are slotted into normal releases
    • you can use special naming flags to identify releases with maintenance tasks
  2. stand alone maintenance releases

Major Releases⌘

  • what is a release?
  • how do you classify major/minor/regular releases?

Creating Change Logs from Git History⌘

  • specialized Git log formatting
    • can be automated and exported to third-party tools if/as needed
  • supported by naming standards
  • more complex scripting can construct tree-logs for any given release

DRY! Dry-software.jpg

Tags for Release Summaries⌘

AKA "release notes"

  • simple to implement note standards in tag descriptions
  • easily extracted for publication in third party tools (i.e. posting to internal wikis via API's)


  • don't squash your commits (after they've made it to a shared/central repo)!
  • closer you move to CI, the less you need to aggrigate individual pieces of work
  • release branches can have task/feature branches merged directly into them
  • management is easiest when devs are most active in the release process

Push Strategies⌘

  • used where the service component is deployed from the centre and pushed out to the target locations
  • typically described in terms of users having no say or participation in recieving new components
  • pushes can be in big bang or phased form
    • big bang = deployment to all users/consumers in one operation
    • phased form = deploying to different groups of users/consumers at different times
  • deployment requires some data for all user/recipient locations, including configuration details

Pull Strategies⌘

  • used for software releases where the release is made available in a central location but users are free to pull at their own leisure
  • concept has gained significant adoption in open source projects
    • another good example is virus signature updates
  • pull strategies require little or no configuration data
  • some pull systems implement a failover that pushes updates when pulls are not frequent enough

Centralize Push/Pull Strategies⌘

  • push and pull strategies are not bound to specific Git/repo configurations
  • centralization requires more standardization
    • including review and testing

A Word on Staging and pre-Production Environments⌘

  • virtualization is your friend
  • weave it all together (Docker, Jenkins, Ansible/Chef, Gulp, etc.)
  • grab a Kit-Kat

Kidkat break.jpg

Dividing Your Application⌘

  • libraries
  • sub-projects
  • binary dependancies

More ugly pictures!

Scripting for DevOps ⌘


DevOps - The Scripts⌘

DevOps - Config⌘

DevOps - VMs⌘

Your CI Butler⌘

Jenkins CI [[1]]

  • the icing on the cake
  • doesn't replace your chef or chauffeur
  • keeps the house running smoothly!

Alternatives to Jenkins: