Track B: Git, CI/CD & Release Engineering Overview

Purpose: Build professional development and release practices that support collaborative engineering and reliable delivery
Philosophy: Version control and automation are not optional tools - they're fundamental engineering disciplines

Track Integration

This track begins in Pre-Semester with Git fundamentals and evolves continuously through all phases, supporting every project and collaborative activity throughout the degree.

---

Track Progression by Phase

Phase	Level	Focus	Skills Developed
Phase 00	Level 1	Git fundamentals	Commits, branches, basic workflow, repository hygiene
Phase 0-2	Level 1	Personal workflow	Project organization, commit discipline, documentation practices
Phase 3-4	Level 2	Code review culture	Pull requests, code review, automated linting and testing
Phase 5-6	Level 2	Build automation	CI pipelines, artifact management, version control integration
Phase 7-8	Level 3	Release engineering	Deployment strategies, release workflows, dependency management
Phase 9-10	Level 4	Production operations	Infrastructure versioning, deployment safety, operational procedures

---

Level 1 Starter Guide: Git Fundamentals

Getting Started Today (45 minutes)

Basic Git workflow for your first project:

1. Initialize your learning repository:

   mkdir cs-degree-portfolio
   cd cs-degree-portfolio
   git init
   echo "# CS & Systems Engineering Portfolio" > README.md
   git add README.md
   git commit -m "Initial commit: Start CS degree portfolio"

2. Create your first learning branch:

   git checkout -b presemester-work
   # Work on Pre-Semester assignments
   git add .
   git commit -m "Complete Pre-Semester Module 1: Study systems setup"

3. Merge back to main:

   git checkout main
   git merge presemester-work
   git branch -d presemester-work

4. Set up remote repository (GitHub, GitLab, or similar):

   git remote add origin https://github.com/yourusername/cs-degree-portfolio.git
   git push -u origin main

Essential Git Commands for Academic Work

Daily workflow:

# Start work session
git status                    # Check current state
git pull                      # Get latest changes (if collaborating)

# During work session  
git add specific_file.py      # Stage specific changes
git commit -m "Descriptive message"  # Commit completed work

# End work session
git push                      # Share changes (if using remote)

Branching for different work:

# Create feature branch for specific module or assignment
git checkout -b module-01-proofs
# Do work...
git add .
git commit -m "Complete proof techniques exercises"

# Switch to different work without conflicts
git checkout main
git checkout -b module-02-combinatorics

Fixing mistakes:

# Undo last commit (keep changes)
git reset --soft HEAD~1

# Undo changes in working directory  
git checkout -- filename.py

# See commit history
git log --oneline

# Compare versions
git diff HEAD~2 HEAD filename.py

Repository Organization for Academic Work

Recommended directory structure:

cs-degree-portfolio/
├── README.md                 # Portfolio overview and navigation
├── docs/                     # Personal notes and documentation
├── semester-00/             # Work organized by semester
│   ├── module-01/           # Module-specific work
│   │   ├── implementations/ # Code exercises and katas  
│   │   ├── notes/          # Personal concept summaries
│   │   └── exercises/      # External platform work  
│   └── projects/           # Semester projects
├── semester-01/
└── tools/                   # Utilities and scripts developed over time

Commit Message Best Practices

Good commit messages explain the "why" not just the "what":

Good examples:

• Implement binary search with edge case handling
• Fix off-by-one error in permutation generator
• Add unit tests for matrix multiplication to catch overflow
• Refactor proof structure for clarity after peer review

Poor examples:

• Update file (what was updated and why?)
• Fix bug (what bug? how was it fixed?)
• Add code (what code? what does it do?)
• WIP (work in progress, but no context about the work)

Commit message template:

[Type]: Brief summary (50 chars or less)

More detailed explanation if needed (wrap at 72 characters):
- What problem this solves
- Why this approach was chosen  
- Any important limitations or assumptions

Refs: #issue-number, external links, or related work

---

Level 2 Skills: Code Review and Collaboration

Setting Up Code Review Process

For academic projects with peer collaboration:

1. Create pull request workflow:

   # Work on feature branch
   git checkout -b feature/probability-simulation
   # Complete implementation
   git push -u origin feature/probability-simulation
   # Create pull request on platform (GitHub, GitLab)

2. Review checklist for mathematical/CS implementations:

   • Correctness: Does the implementation solve the stated problem?
   • Clarity: Can another student understand the approach and reasoning?
   • Testing: Are edge cases and error conditions handled appropriately?
   • Performance: Is the approach efficient for the given constraints?
   • Documentation: Are complex algorithms and design decisions explained?

3. Responding to review feedback:

   # Address feedback on feature branch
   git checkout feature/probability-simulation
   # Make requested changes
   git add .
   git commit -m "Address review feedback: improve error handling"
   git push

Automated Quality Checks

Set up automated linting and testing:

1. Create .github/workflows/ci.yml:

   name: CI
   on: [push, pull_request]
   jobs:
     test:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v2
         - name: Set up Python
           uses: actions/setup-python@v2
           with:
             python-version: 3.9
         - name: Install dependencies
           run: pip install pytest black flake8
         - name: Format check  
           run: black --check .
         - name: Lint check
           run: flake8 .
         - name: Run tests
           run: pytest

2. Configure code formatting:

   pip install black
   black .  # Format all Python files consistently

3. Set up pre-commit hooks:

   pip install pre-commit
   # Create .pre-commit-config.yaml
   pre-commit install

---

Level 3 Skills: Release Engineering and Deployment

Artifact Management and Versioning

Semantic versioning for academic projects:

• MAJOR.MINOR.PATCH format (e.g., 1.2.3)
• MAJOR: Incompatible API changes or fundamental approach changes
• MINOR: Added functionality in backward-compatible manner
• PATCH: Backward-compatible bug fixes and small improvements

Git tagging for releases:

# Tag completed semester work
git tag -a v1.0.0 -m "Complete Semester 1: Mathematical Foundations"
git push origin v1.0.0

# Tag major project milestones
git tag -a v1.1.0 -m "Add probability simulation portfolio"

Documentation as Code

Maintain living documentation with version control:

• Architecture Decision Records (ADRs) for major design choices
• README files with setup instructions and project overview
• API documentation generated from code comments
• Runbooks for operational procedures and troubleshooting

Example ADR structure:

# ADR-001: Choose Python for Mathematical Implementations

## Status: Accepted

## Context
Need to choose primary language for Semester 1 mathematical implementations...

## Decision  
Use Python with NumPy/SciPy for mathematical work...

## Consequences
Positive: Excellent library support, clear syntax...
Negative: Performance limitations for some numerical work...

---

CI/CD Pipeline Evolution

Phase 1-2: Basic Automation

# Simple test automation
- name: Run tests
  run: pytest
- name: Check code style  
  run: flake8 .

Phase 3-4: Enhanced Quality Gates

# Add coverage and security checks
- name: Run tests with coverage
  run: pytest --cov=. --cov-report=html
- name: Security scan
  run: bandit -r .
- name: Type checking
  run: mypy .

Phase 5-8: Service-Oriented Pipelines

# Multi-service testing and integration
- name: Build service images
  run: docker build -t myservice .
- name: Run integration tests  
  run: docker-compose up --exit-code-from tests
- name: Security and vulnerability scanning
  run: docker scan myservice

Phase 9-10: Production Deployment

# Full production deployment pipeline
- name: Deploy to staging
  run: terraform apply -var-file=staging.tfvars
- name: Run end-to-end tests
  run: pytest tests/e2e/ --base-url=$STAGING_URL  
- name: Deploy to production
  run: terraform apply -var-file=production.tfvars
- name: Verify deployment
  run: ./scripts/verify-deployment.sh

---

Advanced Git Techniques by Phase

Phase 3-4: Advanced Branching and History Management

# Interactive rebase for clean history
git rebase -i HEAD~3

# Cherry-picking specific commits  
git cherry-pick abc123

# Searching commit history
git log --grep="bug fix" --oneline  
git log -S"function_name" --oneline

# Bisect for debugging
git bisect start
git bisect bad HEAD
git bisect good v1.0.0

Phase 5-8: Collaborative Development

# Merge strategies
git merge --no-ff feature-branch    # Preserve branch history
git merge --squash feature-branch   # Single commit integration

# Conflict resolution
git mergetool                       # Visual merge tool
git log --merge                     # See conflicting commits

# Advanced collaboration  
git rebase --onto main dev-branch~3 dev-branch  # Complex rebasing
git reflog                          # Recovery from mistakes

Phase 9-10: Release Engineering

# Release preparation
git flow init                       # Git-flow branching model
git flow release start 2.0.0       # Prepare release branch
git flow release finish 2.0.0      # Complete release with tags

# Hotfix workflow
git flow hotfix start critical-bug  # Emergency fix branch  
git flow hotfix finish critical-bug # Deploy critical fix

# Advanced tagging and releases
git tag -s v2.0.0 -m "Signed release"  # Signed tags for security
git describe --tags                     # Version description

---

Common Workflow Patterns

Academic Project Workflow

Solo academic work:

1. Create repository for each semester
2. Use branches for different modules or major assignments
3. Commit frequently with descriptive messages
4. Tag major milestones (module completions, project submissions)
5. Maintain clean documentation for portfolio presentation

Collaborative academic work:

1. Fork-based workflow for peer collaboration
2. Pull request workflow for peer review and feedback
3. Shared repositories for group projects with branch protection
4. Automated testing to prevent integration issues

Professional Development Preparation

Building portfolio for employment:

• Public repositories showcasing best work with comprehensive documentation
• Contribution history showing consistent development practice over time
• Code quality demonstrating professional development standards
• Collaboration evidence through pull request history and code review participation

Open source contribution preparation:

• Study project conventions for repositories you want to contribute to
• Practice contribution workflow (fork, feature branch, pull request, code review response)
• Documentation contributions as entry point to open source participation
• Issue triage and bug reporting to demonstrate engagement with technical communities

---

Troubleshooting Common Issues

"I keep making commit message mistakes"

• Use commit message templates and linting tools
• Practice the "explain to a colleague" approach for commit messages
• Use git commit --amend to fix recent message mistakes before pushing

"My repository history is messy"

• Learn interactive rebase for cleaning up feature branch history
• Use squash merges for feature integration when appropriate
• Focus on clear branch names and logical commit organization

"CI/CD seems overwhelming"

• Start with simple test automation before adding complexity
• Build pipeline incrementally - add one check at a time
• Focus on solving actual problems (broken builds, missed bugs) rather than following tutorials

"I don't understand when to branch vs. when to commit directly"

• Branch for: experimental work, collaborative features, anything that might need to be abandoned
• Commit directly: small fixes, documentation updates, routine maintenance
• Default to branching when uncertain - easier to merge than to separate later

"Code review feels too formal for academic work"

• Start simple: Just ask peers to look at your solution approach and reasoning
• Focus on learning: Use review to understand different approaches and identify blind spots
• Build habits: Practice giving and receiving technical feedback constructively
• Career preparation: Code review skills directly transfer to professional development environments

This track provides the version control and automation foundation essential for collaborative engineering and professional software development throughout your career.