View source for Release with Git - Patrick

[[Category:Git]]

<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="true" font="Trebuchet MS" >
;title: Release Management & Deployment Using Git
;author: Patrick Mazzotta
</slideshow>

==About Us ⌘==
[[File:500res-logo.png|250px]]
* Training & Consultancy Provider
* Founded in 2005
* Currently offering over 400 courses (remote & on-site)
* Continuously exapnding through franchishing opportunities
** http://training-franchise.com

==About Me ⌘==
[[File:Craedone.png|250px]]
* 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 
<br/>[[File:Terms.png|250px]]<br/>
(hint: I'm not a very good book!)

==Primer⌘==
* Project management guides & influences release management
There have been several attempts to develop project management standards, such as:
* ISO 21500: 2012 - Guidance on project management.  This is the first project management ISO.
* ISO 31000: 2009 - Risk management. Risk management is 1 of the 10 knowledge areas of either ISO 21500 or PMBoK5 concept of project management.
* ISO/IEC/IEEE 16326-2009  -   Systems and Software Engineering--Life Cycle Processes--Project Management <ref>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</ref>
* [[Capability Maturity Model]] from the [[Software Engineering Institute]].
* GAPPS, [[Global Alliance for Project Performance Standards]] – an open source standard describing COMPETENCIES for project and program managers.
* [[A Guide to the Project Management Body of Knowledge]] from the [[Project Management Institute]] (PMI)
* [[HERMES method]], Swiss general project management method, selected for use in Luxembourg and international organizations.
* The ISO standards [[ISO 9000]], a family of standards for quality management systems, and the [[ISO 10006]]:2003, for Quality management systems and guidelines for quality management in projects.
* [[PRINCE2]], Projects IN Controlled Environments.
* [[Association for Project Management]] Body of Knowledge<ref>Body of Knowledge 5th edition, Association for Project Management, 2006, ISBN 1-903494-13-3</ref>
* [[Team Software Process]] (TSP) from the [[Software Engineering Institute]].
* [[Total Cost Management]] Framework, AACE International's Methodology for Integrated Portfolio, Program and Project Management.
* [[V-Model]], an original systems development method.
* The [[Logical framework approach]], which is popular in international development organizations.
* [[IAPPM]], The International Association of Project & Program Management, guide to project auditing and rescuing troubled projects.
* [Australian Institute of Project Management] AIPM has 4 levels of certification; CPPP, CPPM, CPPD & CPPE for Certified Practicing Project ... Partner, Manager, Director and Executive.
<references />
==Project Management Standards (1 of 300)⌘==
[[File:Wat.jpg|250px]]

Just kidding!
(... kind of)

==PM boiled down⌘==
PM practices loosely fall under two main categories:
# Waterfall [[File:Waterfall.gif|250px]]
# Agile [[File:AgileDance.gif|200px]]

==Waterfall⌘==
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
[[File:Agile-waterfall.png|250px]]

==Agile⌘==
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
[[File:AgilePlanningOnion.png|250px]]

==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⌘==
[[File:AgileDistribution.png|300px]]

==Leading Methodologies⌘==
#Scrum [[File:Agile-SCRUM.png|250px]]
#Kanban [[File:Simple-kanban-board-.jpg|250px]]

==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⌘==
{| class="wikitable"
|-
! 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
|}<ref name="Kanban vs. Scrum">[https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf Kanban vs. Scrum], PDF reference.</ref>
<references />

==So Now What?⌘==
The objective of Release and Deployment Management is to ensure that:
# There are clear and comprehensive release and deployment plans that enable the customer and business change projects to align their activities with these plans
# A release package can be built, installed, tested and deployed efficiently to a deployment group or target environment successfully and on schedule
# 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
# There is minimal unpredicted impact on the production services, operations and support organization
# 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:
# clear plans are easy to reproduce (and script!)
# efficiency and predictability allows for more repliable planning (see #1)
# especially important for cost and risk analysis, but also provides scope to expectations
# 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)
# 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:
# Discovery and installation software can check whether the required prerequisites and co-requisites are in place before installation of new or changed software components.
# Automated builds can significantly reduce build times that in turn can resolve conflicts and delays.
# Automated configuration baseline procedures save time and reduce errors in capturing the status of configurations and releases during build, test and deployment.
# 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!
[[File:Git central repository model diagram.png|250px]]

==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)
[[File:Tag.png|250px]]

==Switching Between Releases⌘==
* be systematic (programmatic!)
* never veer from tags

==Maintenance & Releases⌘==
There are two approaches to maintenance
# maintenance-as-a-feature
#* fixes and updates are slotted into normal releases
#* you can use special naming flags to identify releases with maintenance tasks
# 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!
[[File:Dry-software.jpg|250px]]

==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)

==Aggrigating⌘==
* 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
** [https://www.docker.com/ Docker] can help!
* weave it all together (Docker, Jenkins, Ansible/Chef, Gulp, etc.)
* grab a Kit-Kat
[[File:Kidkat break.jpg]]

==Dividing Your Application⌘==
* libraries
* sub-projects
* binary dependancies
More ugly pictures!

==Scripting for DevOps ⌘==
[[File:Devops.svg|350]]

==DevOps - The Scripts⌘==
* [https://nodejs.org/ NodeJS] (or [https://iojs.org/en/index.html io.js])
** [http://gruntjs.com Grunt]
** [http://gulpjs.com Gulp]
* [https://www.ruby-lang.org/en/ Ruby]
** [https://rubygems.org Gems]
** [https://github.com/ruby/rake Rake]

==DevOps - Config⌘==
* [http://www.ansible.com/home Ansible]
* [https://puppetlabs.com Puppet]
* [https://www.chef.io Chef]

==DevOps - VMs⌘==
* [https://vagrantup.com Vagrant]
* [https://docker.com Docker]

==Your CI Butler⌘==
Jenkins CI [[http://jenkins-ci.org/]]
* the icing on the cake
* doesn't replace your chef or chauffeur
* keeps the house running smoothly!
Alternatives to Jenkins:
* [https://travis-ci.org Travis CI]
* [https://www.atlassian.com/software/bamboo/#! Bamboo]