Source Control with Microsoft TFS or VSTS and Visual Studio 2017

Module 1: Course Overview
  Systems: TFS or VSTS
    Team Foundation Version Control
    Git
  Setup Git
  Concepts 
  Fundamantal Operations: 
    Create or Clone repo
    Add new file to local repo
    Push to central server for sharing
  Additional commands
    Commit
    Push 
    Fetch 
    Pull
    Advance commands:
      branch 
      rebase
  Popular branching strategies 
    GitFlow
    GitHub Flow
  Gated check-in
    Setup CI, branch policies and Gated check-in

Module 2: Version Control
  Course Introduction
    Git
  Course Objectives
    Understand and use source control
    Primary on Git
  Module Outline
    Source control fundamentals
    Types of source control systems
    Types supported by TFS and VSTS
    Branching Concepts
    CI
  Source Control Fundamentals
    Make changes to files and keep history
      Roll back file
      Identify who has changed what over time
    Some systems also track binary files - but not all
    Ability to roll back file as needed
    Ability to audit changes 
    Foundation to continuous delivery 
  Types of Source Control Systems
    Centralized System: Client Server Model
      User access master copy via the client
      With a copy of project tree stored in local machine
      Changes go to master copy before reaching other users
    Distributed System: Repos as peers
      Local repo w/ version history + working copy
  Centralized and Distributed Source Control Systems
    Centralized System typically used in organization
      Strength: 
        Handle large codebase
        Fine level permission control
        Usage monitoring 
        Exclusive locking 
    Distributed System
      Strength:
        Full offline experience & Speed 
          - roll back, branch and merge locally
        Fast operation
        Access full history locally 
          - Who make what change and when
        Cross platform 
        Popularity 
        Pull request for code review (from GitHub)
  Create a Team Project with Centralized and Distributed Source Control in VSTS
    TFVC can co-exist with Git under the same project
  Branching
    Branching allows coding in isolation 
      - To build something that's not code complete without breaking code base
    Branching = make a copy of source + apply changes to that copy
    Copy vs. Branch
      Relationship and history w/ source is awlays maintained
        - This information is useful when merging with main branch 
      Branch is created with intent to merge back to where it is made from
    At merge, a traceable history to branch and parent is made
    Git can combine multiple commits on branch into one bigger change, then merge into main branch
      - the changes made to source are available for auditing
    Branching Patterns: HOW & WHEN to create branch should be standardized
      - which branch to maintaine
      - which branch go into production
      TFVC: branches are created on server by default, availabe to everyone in the team
      Git: branches are created locally first, published later
      Guide to branching: http://bit.ly/branchingguide
  
  Connecting to Team Foundation Version Control and Creating a Branch
    Start VS 2017 -> Team Explorer -> Manage Connection
    With option for GitHub and VSTS
    When connect, repos are available based on the login credentials 
    Once connected with repo, workspace (where server files are mapped to local machine) can be set up
    Once workspace is created, files on server can be downloaded to local workspace via Source Control Explorer 
    At this point, user may opt to add project folders to workspace folder 
    Then open the added project (.csproj file) in visual studio 
      - use the IDE to filter out items not wanted in version control system, like binaries generated in OBJ folder
    Right click on newly added solution in solution explorer 
      - Select "Add solution to Source Control"
    Right click on newly added solution in solution explorer, Again
      - Select "Check In..."
    Add Comment, then click "Check In" (The new project is now available on server)
    
    To Create a New Branch:
      Inside Source Control Explorer, R-Click the newly added folder, select "Branching and Merging" -> "Branch"
      Name the new feature branch -> Then click OK (Branch created)
        Recommand to check "Download the target item to your workspace" &
        "Immediately convert source folder to branch (enable visualization)"

    To verify the branch relationship:
      R-Click on branch 
      Select "Advance" -> "Properties" -> select "Relationship" panel

    To switch from main branch to different branch:
      Open "Source Control Explorer"
      Double click on solution inside the branch to switch to
      Verify files in solution explorer is now in folder for different branch
      (Optional: Merge back to Main branch) 
        Add some comment to code and check in
        Go back to Source Explorer
        R-Click on the branch with changes 
        Select "View History"
        Select changeset to merge 
        Click "Track Changeset" button on top
        Click "Visualize" button to see the relationship b/t the selected changeset to a specific branch
        Click "Timeline Tracking" button on top to see the feature & main branch timeline
        Drag and drop changeset from one timeline to another (feature to main) to start merge wizard
        (Click through "Next" to verify folder location and changeset number, then confirm merge )
        The change now is a pending change on main branch (But NOT committed YET)
        On main branch, select files with pending change, R-Click then select "Check in Pending Changes",
          provide comment and then "Check In"
        (Visualize history again) Now the changeset has been merged from feature branch timeline to the main branch timeline

  Continuous Integration
    Put changeset to source ASAP to reduce time of working in isolation -> need for CI
    CI: the practice of merging all devs' working copies to a shared mainline several times a day
    However, the new code need to be validated -> consistently build and verify code behaviors with unit test 

  Continuous Integration with Visual Studio Team Services
    Demo
  Summary
    
Module 3: Source Control with Git on TFS or VSTS
  Introduction
    Option to setup multiple Git repos in a project
    How to set it up using Git as source provider 
  Overview
    Understanding Git & Set up repo 
    Basic Git operation in VS
    Git Branching 
    Branching strategies and CI/CD
      Git Flow
      Git Hub Flow
  Understanding Git - to avoid losing code!
  Git is All About a Graph of Nodes
    At the creation of a new repo, the only thing created is the administration of the graph 
    One reference called head points to the start of the graph at the FIRST commit
    A git commit is a node (in a graph) that contains a pointer to the data 
      - In Git, every commit contains a pointer to the snapshot of ALL data
    When NEW code is committed, a new node is created with a "parent" pointer points to the previous commit
    There is always at least ONE reference - the Head: This is where we are at the repo
    All tasks in Git are:
      Manipulating nodes
      Referencing nodes  
    References make commits reachable
      Head, Tag, Branch
  Creating a Git Repo in TFS/VSTS (DEMO)
    VSTS -> Code (Tab) -> 
    1. git init on source folder in command prompt
    eg. 
      C:\TestServerAndInMemoryDbDemo>git init
      Initialized empty Git repository in C:/TestServerAndInMemoryDbDemo/.git/
    2. Create .gitignore file to avoid to upload binary files 
      A template for Visual Studio can be found at https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
      Click "Raw" button 
      Copy and Paste the file into a new text file (x.gitignore for now)
      (On command prompt) Run "ren x.gitignore .gitignore"
      This is not possible to do in file explorer
    3. Add .gitignore to LOCAL repo
      (On command prompt) Run 
        git add .gitignore
    4. Commit the change
      (On command prompt) Run 
        git commit -m "git ignore"
    5. At this point, Add all files in local folder
      (On command prompt) Run 
        git add * 
    6. Commit the change to local repo
      (On command prompt) Run 
        git commit -m "Initial sources"
    
    ....

    Add remote origin points to VSTS server 

  Basic Git Operations
    Clone: Use repo / source code already in server   
  
  Cloning a Git Repo in Visual Studio
    (DEMO) VSTS -> "Clone" button -> Select Clone in VS option
    -> Specify where to clone in local machine (with VS)
    -> Verify previous changes and history 
  
  Basic Git Operations-2
    After "Clone", add source code and make changes to sources on loacl machine
    Then notify source control system of changes, use "Stage" to stage changes to Git
    Once a consistent sources staged, use "Commit" to commit to the local repo 
    To share changes in local, "Push" to any other clone 
      - like any machine with the same repo, but likely a server
    For others to get our code:
      1. Fetch: 
        ONLY Check IF there are changes from other repos
        Get list of changes from other source repos (but NOT actual changes)
      2. Pull:
        Pull changes to local repo, and updates any file locally with changes from server 
        When pulling, there can be NO local changes pending 
          - the yet-to-commit changes can get lost when pulling changes
          - Always commit first before pull  
  
  Using Fetch, Push, and Pull (DEMO)

  Git Branching
    Master branch: At least one branch in Git
    Branch = Pointer to a node in the tree of commits
    Create branch is fast, just make a new pointer to the current commit node 
    
    Create branch locally, then publish a branch to server to share  
    
    Merge: local operation to create a change on target branch
      After edit on local workspace is done, commit changes to local branch
      This needs to be pushed to server before sharing
  
  Branch, Merge, and Rebase
    Standard Merge: Changes are made to both Master and Feature branch
      "Merge" command can be used to merge branch to master
      This will create a new commit node on Master branch that contains merged changes
    
    Fastforward Merge: w/ No changes on master branch
      The originating node on master that creates branch has yet changed
      Move pointer to the end of master to the end of branch 
      Thus, end of branch = end of master 
      No new commit node is created   
    
    Rebase: Changes are made to both Master and Feature branch
      Before merge to main branch, need to catch up with changes on master  
      "Catch up": replay each change in master branch on feature branch 
      Then fastforward merge to consolidate master and feature branch 

  (Branch and) Merge and Rebase - DEMO
    (On VSTS) Open "Code" tab, verify commits 
    (On VS) Team Explorer -> Branches 
      R-Click on Master -> Select "New Local Branch From..."
      -> Name the feature branch and click "Create Branch"
    
    (Go back to Master branch - double click on Master Branch)
      Make some changes on master branch then commit it
      -> Sync -> Push
      (Now master is one commit node before feature branch)
    
    (Go back to Master branch - double click on Master Branch)
      Make some changes on feature branch then commit it
      -> Sync -> Push
      Verify that change in feature branch is registered with "View History..."
    
    (Go back to Branches)
      R-Click on master -> Select "Merge From ..."
      -> Click "Merge" (creates "Merge Commit")
      Verify that change in feature branch is now on master branch (with a new commit) with "View History..."
      R-Click on master branch and "Push" to the server
    
    (Now Repeat the same task on another feature with Rebase )
      First delete previous feature branch

      ... more details to cover

  The Git Pull Request
    Scenario: A request from someone else who creates feature branch to take the change and merge into main code line
    Pull request: 
      A tooling to 
        have some discussion / review on the submitted code 
        change the code again before merge
        setup standard mechanism to perform the merge 

  Pull Requests in TFS/VSTS (DEMO)
    Create a feature branch from main branch
    Switch workspace to the new feature branch and add code changes
    R-Click on the changed file and select Commit to commit to local repo
    Stage the file then add commit message
    Sync with server then push to server
    Notice that after push to feature branch, there is a link for
    "Create a pull request". Click on it.
    Notice that a browser window titled "Create Pull Request" is opened
    Add title and description, select reviewer and work item ID for the PR, then click "Create"
    
    (For reviewers to work with the PR)
    Code (tab) -> "Pull Requests" then select a specific PR
    Select "Files" to view changes in file
    Comment inline as needed 
    Reviewer and vote for Approve, Approve w/ suggestions, Wait for author or Reject
      if a PR is "Rejected", then it cannot be merged 
    Selecting "Complete" will merge changes into branch 
    
  Branching Strategies and CI/CD
    When moving to continuous delivery, keep branching at a minimum
    Consider feature toggles over branching 

  Git Hub Flow 
    One stable massive branch to release from 
    Feature branch with the name of feature been worked on at the moment 
    To share code, create PR
    To deploy feature, 
      first deploy feature to production and varified there is no issues
      then merge to Master
        - This merge needs to be standardized: 
            such as: Always rebase? Simple merge? 
            Squash all commits to one single change that gets merge?
            Or keep individual commit as part of the final history 
      Merge to main is often done through PR
      Track which feature move to main and eventually part of product 
    Git Hub Flow
      Best suited for continuous deployment  
      Release multiple times a day
      Delivery of Software as a Service (SAAS) - cloud based solution
    
  Git Flow
    A set of branches 
      Master: always stable to release 
      others work up to the release of the software in production
        Hotfix
        Release 
        Dev
        Feature X
    Software delivered in build cycles 
      Work up to a milestone
      Stablized the build 
      Release
    Common for projects w/ deliverable like 
      NuGet packages
      Libraries 
      Complex suite w/ many integrations
    Continuous Delivery is possible but require discipline and process

  The Git Flow Branching Strategy
    source: https://nvie.com/posts/a-successful-git-branching-model/
    
    Origin: 
      a central git server
      source of truth for a centralized build and release process
        members can work distributed in isolation
        push to and pull from server as needed
    
    At start of work:
      Create a clone of repository
      Work locally on assigned feature
      When done, pushes changes up to central repo

    Multiple members work on the same feature:
      1. Publish to the branch collaborate on, or 
      2. Share branch with those interested, but other members won't see the work until pushed to the central server 

  Git Flow Branches
    Branch types:
      Master: 
        only commit stable changes
        only release from master into production
        all commits are fully tested, stable and don't need additional work
        assume to go to production asap
      Dev:
        where development is done
        contains all committed and tested features after work is done in feature branches
        also assume to be always stable
      Release:
        short-live branch 
        only for stablizing codebase 
        only fix issue found in final acceptance test
        should be able to add stright to master and release to production
      Feature:
        Where work is done
        Roll back as needed
        Merge to Dev branch after work is done
        Delete feature branch
        Merge to dev with additional flag, no fast forward will keep local history and add to dev branch 
        Or squash code changes before merging 
    
    Keep branch histry as a record for traceability 
    Keep history as stright line
      Use Rebase to keep history as stright line 
      No fast forward commit is recommanded   

      Hotfix: 
        production issue that need immediate fix
          merge directly into master & dev

  Main, Supporting, and Hotfix Branch
    Main branches: Master / Dev / Release 
      Always release from Master (primary branch - Always stable)
      Daily work done on Dev branch
      Release branch created to stablize (and move to master) for release 
        - this branch is optional if you have high confidence on code quality
        - Merge to master / Merge back to dev at the same time - so that stablized code feedback to the next release 
    Supporting branches: Feature
      Whenever there are code changes, create feature branch 
      For cooperation:
        Share branch to push to and pull from each other 
        Alternatively, central help:
          public feature branch to origin repo
          use it as central hub for committing the changes 
          once done, merge to DEV branch then delete branch
        Although feature branch is never kept, 
          branch history can be kept OR
          squash history before commit 
    Hotfix branch
      Create new branch off latest Master commit 
      Make changes (and maybe few commits) and test
      Merge change into Master and Dev branch 
      Delete branch after issue fixed 

  Git Flow in Action
  Summary

Module 4: Implementing Continuous Integration
  Introduction
  Outline
  Continuous Integration
  Setting up Continuous Integration for TFVC
  Setting up TFVC Gated Check-in
  Setting up Gated Check-in
  Setting up Continuous Integration Builds with Git
  Setting up Continuous Integration with Git
  Setting up Git Branch Policies
  Setting up Branch Policies
  Summary