Merge pull request #20 from NETWAYS/feature/enhance-workflows

Michael Friedrich · web-flow · commit 89b1ccba1fa9 · 2018-10-29T16:57:55.000+01:00
Enhance Git Workflows
diff --git a/_images/workflows/git_forking_workflow_01.png b/_images/workflows/git_forking_workflow_01.png
diff --git a/_images/workflows/git_gitflow_workflow_01.png b/_images/workflows/git_gitflow_workflow_01.png
diff --git a/day2/01_Workflows/01_Intro.md b/day2/01_Workflows/01_Intro.md
@@ -8,7 +8,7 @@
 * Single user environments
 * Multiple users working together
 * Branching models
-* Patch and pull request workflow integration
+* Merge and pull request workflow integration
 
 ~~~SECTION:handouts~~~
 
diff --git a/day2/01_Workflows/02_Centralized.md b/day2/01_Workflows/02_Centralized.md
@@ -1,9 +1,10 @@
 !SLIDE smbullets
 # Centralized Workflow
 
-* Multiple users
-* Each user has a local copy
-* Central `master` branch
+* Developers clone the central repository
+* Work in local copies
+* New commits are stored locally
+* Importing the remote repository's changes is optional
 
 <center><img src="../../_images/workflows/git_centralized_workflow_01.png" alt="Centralized Workflow"/></center>
 
@@ -25,22 +26,6 @@ for integrating and sharing code changes between repositories.
 ~~~ENDSECTION~~~
 
 
-!SLIDE smbullets
-# Centralized Workflow - Developers
-
-* Developers clone the central repository
-* Work in local copies
-* New commits are stored locally
-* Importing the remote repository's changes is optional
-
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
-
 !SLIDE smbullets noprint
 # Centralized Workflow - Publish Changes
 
@@ -169,7 +154,7 @@ The last parameter specifies the target directory `training2`.
 
 
 !SLIDE smbullets noprint
-# Centralized Workflow - Managing Conflicts Solution
+# Centralized Workflow - Managing Conflicts: Rebase History
 
 * Fetch the remote history
 * Rebase local changes on top of it
@@ -178,7 +163,7 @@ The last parameter specifies the target directory `training2`.
 <center><img src="../../_images/workflows/git_centralized_workflow_04_example.png" alt="Centralized Workflow"/></center>
 
 !SLIDE smbullets printonly
-# Centralized Workflow - Managing Conflicts Solution
+# Centralized Workflow - Managing Conflicts: Rebase History
 
 * Fetch the remote history
 * Rebase local changes on top of it
diff --git a/day2/01_Workflows/03_Feature_Branch.md b/day2/01_Workflows/03_Feature_Branch.md
@@ -28,7 +28,6 @@
 !SLIDE smbullets
 # Feature Branch Workflow - How it works
 
-* Central repository
 * Create a new branch for each feature
 * Descriptive branch names, e.g. `feature/docs-workflows`
 * Changes in a feature branch similar to centralized workflow
diff --git a/day2/01_Workflows/04_Gitflow.md b/day2/01_Workflows/04_Gitflow.md
@@ -17,16 +17,6 @@
 
 ~~~ENDSECTION~~~
 
-!SLIDE smbullets noprint
-# Gitflow Workflow
-
-<center><img src="../../_images/workflows/git_gitflow_workflow_01.png" alt="Gitflow Workflow"/></center>
-
-!SLIDE smbullets printonly
-# Gitflow Workflow
-
-<center><img src="../../_images/workflows/git_gitflow_workflow_01.png" style="width:480px;height:263px" alt="Gitflow Workflow"/></center>
-
 !SLIDE smbullets noprint
 # Gitflow Workflow - Historical Branches
 
diff --git a/day2/01_Workflows/06_Github_Flow.md b/day2/01_Workflows/06_Github_Flow.md
@@ -1,26 +1,9 @@
 !SLIDE smbullets
 # Forking Workflow with GitHub
 
-* Every developer has
- * a server-side repository
- * a private repository as copy of the server-side repo
-* Developers push their own server-side repository
-* Project maintainer pushes to official repository
-
-<center><img src="../../_images/workflows/git_forking_workflow_01.png" alt="Forking Workflow"/></center>
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
-
-!SLIDE smbullets
-# Forking Workflow - How it works
-
-* Developers fork, commit and push into their own repository
-* Developers create a `Pull Request` for the official repository, CI triggers automated tests for the PR
+* Fork aka "create a copy" of the server-side repository
+* Commit and push into own repository copy
+* Create a `Pull Request` for original repo, CI runs automated tests
 * Developers/Maintainers review and merge PR, CI triggers deployment task
 
 <center><img src="../../_images/workflows/git_github_workflow.png" alt="GitHub Workflow"/></center>
@@ -40,26 +23,22 @@ GitLab: https://docs.gitlab.com/ce/workflow/forking_workflow.html
 # Forking Workflow - Multiple Remote Repositories
 
 * **Multiple** remote repositories
- * `origin` is yours, e.g. git@github.com:dnsmichi/icinga2.git
+ * `origin` is yours, e.g. https://github.com:dnsmichi/icinga2.git
  * `upstream` is official with releases, e.g. https://github.com/icinga/icinga2.git
 * Merge branches from `origin/<branch>` to `upstream/<branch>` and vice versa
 
 Example:
 
     $ git remote -v
-    origin	git@github.com:dnsmichi/icinga2.git (fetch)
-    origin	git@github.com:dnsmichi/icinga2.git (push)
+    origin	https://github.com:dnsmichi/icinga2.git (fetch)
+    origin	https://github.com:dnsmichi/icinga2.git (push)
     upstream	https://github.com/icinga/icinga2.git (fetch)
     upstream	https://github.com/icinga/icinga2.git (push)
 
 ~~~SECTION:handouts~~~
 
 ****
 
-
-~~~ENDSECTION~~~
-
-!SLIDE smbullets
 # Forking Workflow - Keep in Sync
 
 * Pull changes from `upstream` HEAD to own repository master branch to sync development
@@ -73,10 +52,6 @@ Example:
     $ git pull upstream HEAD
     $ git push origin master
 
-~~~SECTION:handouts~~~
-
-****
-
 
 ~~~ENDSECTION~~~
 
diff --git a/day2/01_Workflows/07_Gitlab_Workflow.md b/day2/01_Workflows/07_Gitlab_Workflow.md
@@ -1,8 +1,8 @@
 !SLIDE smbullets
 # GitLab Workflow
 
-* Manage roles and permissions
-* Developers create `Merge Requests` from branches, tests and CI builds run automatically
+* Manage branch access with roles and permissions
+* Create `Merge Requests` from branches, CI runs tests/builds automatically
 * Review and inline code comments
 * Project maintainer merges requests and manages issues/milestones/releases
 
diff --git a/day2/01_Workflows/08_Practical_Workflow_Examples.md b/day2/01_Workflows/08_Practical_Workflow_Examples.md
@@ -1,14 +1,19 @@
-!SLIDE smbullets
-# Practical Examples for Git Workflows
+!SLIDE smbullets small
+# Workflow Examples: Icinga 2
 
-If you are using GitHub/GitLab repositories, use forking and pull/merge requests.
+* Feature branch workflow
+* `master` as development branch
+* Major releases from `master`, `support/x.y` for bugfix releases
 
-Smart adoptions of the Gitflow workflow could include the following:
+Moving to GitHub, we extended this to:
 
-* development branch (`master`)
-* release branches (`support/<version>`)
-* Fix and feature branches are based off the `master` branch
-* Bugfixes are cherry-picked into the release branches
+* (WIP) Pull Requests, local and community forks
+* Travis CI (Linux) & Appveyor (Windows) automated tests
+* Developers review and approve PRs, maintainer merges
+* Maintainer prepares and publishes a release
+
+https://github.com/Icinga/icinga2/blob/master/CONTRIBUTING.md
+https://github.com/Icinga/icinga2/blob/master/RELEASE.md
 
 
 ~~~SECTION:handouts~~~
@@ -18,3 +23,21 @@ Smart adoptions of the Gitflow workflow could include the following:
 
 ~~~ENDSECTION~~~
 
+
+!SLIDE smbullets small
+# Workflow Examples: Icinga Exchange
+
+* Issue management in GitLab with milestones and boards
+* Developers create Merge Requests from local branches
+* CI jobs run unit and Mock tests (GitHub oauth, etc.)
+* Maintainer reviews MRs and merges
+* Maintainer creates a new release
+* Manual deployment via Puppet and release tags
+
+
+~~~SECTION:handouts~~~
+
+****
+
+
+~~~ENDSECTION~~~
