Part 1: GitLab Overview

• What is GitLab?
• Sequential DevOps vs. Concurrent DevOps
• Concurrent DevOps with GitLab
• GitLab Flows
• GitLab Recommended Process
• GitLab Workflow Components
• Demo Exercises: GitLab Features

Part 2: GitLab Components and Navigation

• GitLab Organization
• GitLab Epics
• Issue: The Starting Point for your workflow
• Issue Organization
• GitLab Workflow Example
• Demo Exercises: GitLab Navigation
• Hands-On Labs: Create a Project & Issue

Part 3: Git Basics

• What is Git?
• Git Key Terms
• Why Git is so popular
• Centralized vs. Distributed
• Basic Git workflow within GitLab
• Common Commands
• Demo Exercises: Working Locally with Git
• Hands-On Labs: Working Locally with Git

Part 4: Basic Code Creation in GitLab

• Code Review- Typical Workflow
• Code Review Workflow- GitLab tools to use
• Additional Tools for Code Review & Collaboration
• Demo Exercises: Merge Request in GitLab
• Demo Exercises: Assigning, Reviewing, and Approving in GitLab
• Demo Exercises: Additional Tools for working with code
• Hands-On Labs: Code Creation and Review

Part 5: GitLab's CI/CD Functions

• What is CI/CD?
• CI/CD Advantages
• Concurrent DevOps lifecycle
• CI/CD Features in GitLab
• CI/CD Automated tasks
• GitLab CI/CD Key Ingredients
• Anatomy of a CI/CD Pipeline
• Demo Exercises: CI/CD Examples
• Hands-on Labs: CI/CD Pipelines

Part 6: GitLab's Package and Release Features

• What are Package and Container Registries?
• Release Features in GitLab
• What is Auto DevOps?
• Demo Exercises: Auto DevOps and Interactive Web Terminal

Part 7: GitLab Security Scanning

• Demo Exercises: Using SAST Templates
• Hands-On Labs: How to run a SAST scan
• Hands-On Labs: View the scanning reports in the Security Dashboard

Part 1: GitLab Overview and Organization

• GitLab Workflow Components
• Planning a Project
• The Plan Stage: Project Management
• GitLab Organization – Groups, Projects, and Issues, oh my!

Part 2: GitLab Plan Stage

• Organizing the Work
• Planning the Work
• Doing the Work
• Document the Work
• GitLab Agile Planning Structures

Part 3: Planning Functions in GitLab

• Issues: The Starting Point for your Workflow
• Issues Keep Everyone Connected and Synchronized
• What Can you Expect on an Issue Page?
• Hands-On Lab: Issues and Labels
• Hands-On Lab: Quick Actions
• Why Milestones are Important
• The Use of Kanban Boards
• GitLab's Service Desk
• Utilizing Wikis
• Hands-On Lab: Create a Wiki Page
• Hands-On Lab: Epics and Kanban Boards
• Project Management Review Quiz
• Hands-On Lab: Practice Lab 1
• Hands-On Lab: Practice Lab 2

Part 1: Introduction

1. Required knowledge
   1. Git: Committing code and creating pull requests
   2. Kubernetes: Deploying a service to Kubernetes and basic checks with kubectl
   3. Docker: Pushing an image to a Docker repository
   4. CI/CD: GitOps reverses the traditional understanding of continuous integration/continuous development.
2. Core concepts: A quick introduction
   1. Immutable infrastructure
   2. Infrastructure as code
   3. Orchestration
   4. Convergence
   5. CI/CD
3. What GitOps is not
   1. GitOps is not infrastructure as code.
   2. GitOps doesn't replace continuous integration (CI).
4. The use case: Deploying a highly available microservice
   1. Deploying a microservice to Kubernetes, with all the surrounding infrastructure to make it available

Part 2: Setting up the Tools

1. Kubernetes
   1. In advance: Setting up a cluster from scratch is time-consuming, even if you use a managed solution like EKS. Pre-allocating a cluster per person is something you can do in advance.
2. Preparation: Setting up kubectl
   1. Every participant should have credentials to connect to the cluster using kubectl.
3. Preparation: Access a cluster through kubectl/k9s.
   1. Check running pods.
      1. Check deployments.
4. Repository
5. Preparation: Infrastructure repository
   1. An empty repository in GitHub/GitLab to use for deploying infrastructure
6. Application repository
   1. Strictly speaking, you don't need to separate the application and infrastructure, but it's easier to understand what goes where this way.
      1. A sample application that serves a web server with a hello world response as the baseline (NodeJS-based, for instance)
7. ArgoCD
8. Why ArgoCD?
   1. ArgoCD is tightly integrated with Kubernetes and closely follows the GitOps mindset. Therefore, it's a good tool to showcase GitOps.
9. Exercise: Add ArgoCD to the cluster.
   1. Create namespace.
   2. Deploy ArgoCD to the cluster.
   3. Access ArgoCD using the CLI.

Part 3: Deploying a Microservice

1. Exercise: Prepare a simple microservice to be deployed in k8s.
   1. Build sample application as a Docker container (Dockerfile can be provided in advance)
   2. Push service to a Docker registry (cloud-native, docker.io, or quay.io)
2. Exercise: Create a k8s deployment.
   1. Create a Kubernetes deployment definition in code for the application (here's a sample).
   2. Push code to infrastructure repository.
   3. Create an application in ArgoCD.
   4. This time, you'll use the ArgoCD CLI so you can see that part. You'll move to use Git from here on, which is more aligned to GitOps.
   5. Sync the application.
   6. Again, use the CLI.
   7. Test: Use kubectl check to ensure that deployment works.
3. Automated synchronization
   1. Pull versus push: How ArgoCD can read from a repository and automatically apply the changes
   2. Exercise: Activate synchronization so that further changes happen when you push code to the infrastructure repository.
4. Exercise: Create a k8s service. (A deployment alone doesn't expose the microservice, so let's build on that.)
   1. Create service definition.
5. Pull request
   1. This is an opportunity to introduce the pull request aspect of the flow. You can extend pull requests so that extra checks are performed, using something like GitHub Actions.
      1. Implementing CI with something like GitHub Actions isn't part of the exercise, although it's something that you can complete as an extra exercise. (See the bonus section at the end of this post.)
      2. Test: Carry out a kubectl check to prove that service was deployed.
6. Exercise: Create a load balancer. (You still can't access service from the outside.)
   1. Create loadbalancer k8s definition for cloud provider.
   2. Pull request
   3. Test: Curl to load balancer address to ensure that service is actually online.
7. Exercise: Update the application.
   1. Change something in the application, such as the body of the response of a route in the application.
   2. Rebuild container with a new tag and push it to Docker registry.
   3. Update k8s deployment to use new tag.
   4. Pull request
   5. Test: New version of the app should be deployed.
8. Exercise: Update the infrastructure. (Why do this? So you can demonstrate that changing the application and the infrastructure results in blurry boundaries.)
   1. Update k8s deployment to be highly available (more than one replica).
   2. Pull request
   3. Test: kubectl shows that there are multiple pods running.
9. Wrap-up: This covers the workflow of deploying an application and then performing updates and changes on it.
   1. This is the core of GitOps!
   2. There are also other, more advanced use cases to cover.

Part 4: Promoting Changes Through Different Environments 

1. In advance: Prepare a second cluster.
   1. As with the first cluster, this is something to have prepared in advance.
2. Preparation: Register the cluster in ArgoCD to allow deployments to it.
3. From development to production
   1. Which options are there to represent different stages?
   2. This is an open discussion, as there's no set recipe to do environment promotion, with different options:
   3. Use different infrastructure repositories.
   4. Use different folders in the same infrastructure repository.
   5. Use branches.
4. Exercise: Promotion of a version
   1. Set up a second cluster (production) to read from a different folder.
   2. Copy the infrastructure created for the first folder into this one.
   3. Pull request
   4. Test: Second cluster should have the service available as well.
5. More advanced deployment scenarios (Controlled release is an important part of releasing traffic, especially to production. It's worth talking about the options that you have that can be based on the exact same building blocks as explained before.)
6. Exercise: Blue/Green
   1. Enable Argo Rollouts in cluster.
      1. Test: Observe rolling deployment with kubectl.
   2. Install argo-rollouts plugin for kubectl.
   3. Create rollout to apply to existing microservice.
7. Canary release
   1. Theory only (This can be a good lead-in to a discussion of the merits and tradeoffs of different deployment strategies.)
8.  Exercise: Error handling (This exercise shows that failure in infra deployment is expected and is handled through code changes—not panicked actions!)
   1. Introduce an error in the hello world application (this results in a thrown exception instead of starting the webserver).
   2. Rebuild the container with a new tag and push it to Docker registry.
   3. Update k8s deployment to use new tag.
   4. Pull request
   5. Test: Confirm with kubectl that deployment is failing.
   6. Revert a failed change through code.

Part 4: Security in GitOps

1. Accessing resources
   1. kubectl shouldn't replace observability, such as logging and monitoring (similar to secure shell—SSH—into a production server)
2. Secrets
   1. No plaintext secrets should ever be stored in Git.
3. Vault
   1. This is theory only because it's probably too much to do for a practical exercise.
4. Exercise: Sealed secrets
   1. Depending on time, this can be treated as theory or as an exercise. Furthermore, you can split it in two depending on how much time you have.
      1. Modify microservice to read the secret and make it available through a request.
   2. Provision secrets in the infrastructure repository.
   3. Use secrets from either the cluster or the application.
   4. Install the sealed secrets controller.
   5. Inject an encrypted secret in the infrastructure repository.
   6. Modify Kubernetes deployment to inject a secret into the microservice.

Part 7: Recap

1. Core concepts: Infra as code, Git as the source of truth, pull model, converging changes
2. Core flow: declare infrastructure, commit it, pull request for review, merge to apply
3. Next steps
   1. Automated promotion (If a deployment to a staging environment succeeds, then trigger a deployment to production.)
   2. Observability (microservices that export metrics, logging aggregator, and monitoring)

Bonus exercises

1. Replace manual steps (push Docker container, build application code) with CI, such as GitHub actions.
2. Introduce templating (Jsonnet, Helm) to foster reuse of Kubernetes resources.
   1. Exercise: Parameterize deployment so that port can be defined as configuration. Deploy a second copy of the same service with a different name, running on a different port.
3. Install more advanced resources in the cluster using the same mechanism, such as an ingress controller.

Part 1: Course Introduction

1. Azure Repos-Chef-Azure Pipelines: A DevOps Pipeline
2. Course Purpose
3. Agenda
4. Introductions
5. Lab Environments

Part 2: Technology Overview

1. Git – Source Control Management
2. Chef – Configuration Management
3. Azure Pipelines – Continuous Integration
4. An End-To-End CI/CD (Continuous Integration/Continuous Deployment) Pipeline

Part 3: Git/Azure Repos – Source Control Management

1. Git purpose and Workflow
2. Git configuration
3. Getting help with git
4. Basic git commands
5. Remote, status, add, commit, push, log, diff
6. Creating and checking out branches
7. Creating a repository in Azure Repo
8. Accessing a private repository with SSH keys
9. Pull requests
10. Merging and deleting branches

Part 4: Chef – Configuration Management

1. Chef purpose and use cases
2. Chef basics: Resources, recipes, and cookbooks
3. Chef policy files
4. Integration testing with Inspec and Test kitchen
5. Chef variables: Attributes and Ohai
6. Dynamic file creation with templates
7. Using Chef Supermarket and community cookbooks
8. Wrapper cookbooks
9. Automating infrastructure with Chef Search
10. Centralized management with Chef Infra Server
11. Automating Chef convergence
12. Managing nodes with policy groups

Part 5: Azure Pipelines

1. CI/CD = Continuous Integration / Continuous Deployment
2. Purpose
3. Projects
4. Jobs
5. YAML scripting – CI/CD as Code
6. Managing credentials and secret files
7. Integrating with Source Control Management: Azure Repos
8. Triggers: Scheduled Polling and Webhooks
9. Automated cookbook linting: Foodcritic and Cookstyle
10. Automated cookbook testing with Test Kitchen
11. Azure Pipelines Integration with Chef Server
12. Creating Separate Build and Release Pipelines
13. Continuous Deployment of Chef cookbooks with Azure Pipelines

Part 1: Technology Overview

1. Git – Source Control Management
2. Ansible – Configuration Management
3. Jenkins – Continuous Integration/Continuous Deployment

Part 2: Git – Source Control Management

1. Purpose overview and use cases
2. Git workflow
3. Configuring git on your local machine
4. Getting help with Git
5. Local vs. Global vs. System configurations
6. Basic Git Commands
7. Creating local git repositories
8. Branching and merging
9. Using remote repositories
10. Pushing code to Github using public and private SSH keys

Part 3: Ansible – Configuration Management

1. Ansible purpose and use cases
2. Architecture and call flow
3. Ansible installation, configuration, and validation
4. Control nodes and managed nodes
5. Ansible managed hosts
6. Host inventory; hosts and groups
7. Repeatable code: Playbooks
8. Introduction to YAML
9. Modularizing code: Roles
10. Ansible variables
11. Dynamic configuration with facts
12. Finding errors: Ansible unit testing
13. Ensuring code quality: Ansible integration testing

Part 4: Jenkins – Continuous Integration / Continuous Deployment

1. CI/CD overview, use cases and history
2. Plugin architecture
3. Initializing a Jenkins server
4. Projects and jobs
5. Freestyle jobs
6. CI/CD as Code: Pipeline projects
7. Declarative vs. scripted pipelines
8. Jenkins Environment variables and parameters
9. Distributed architecture: Master and agent nodes
10. Views and Folders
11. Managing credentials and secrets
12. Integrating with git Source Control Management
13. Triggers: Webhooks and Polling
14. Notifications: Instant messaging and SMTP Email
15. Approval inputs
16. Testing Ansible playbooks in Jenkins
17. Multibranch Pipelines: Reading entire repositories
18. Conditional Logic
19. Deploying Ansible playbooks with Jenkins: An automated end-to-end deployment pipeline

Part 1: Source Control Management with Git

1. Purpose and overview of Git
2. Use cases for Git
3. Git flow
4. Git providers
5. Git configuration
6. Finding help on Git
7. Creating Local Git Repositories
8. Basic Commands: add, commit, status, log
9. Comparing commits: git diff
10. Using a Repository: git push
11. Branches: creating, merging and deleting
12. Resolving merge conflicts
13. Managing Pull Requests
14. Using SSH keys with git platform private repositories

Part 2: Continuous Integration/Continuous Deployment with Jenkins

1. Continuous Integration / Continuous Delivery (CI/CD): Jenkins
2. CI/CD = Continuous Integration / Continuous Deployment
3. Jenkins use case, purpose & history
4. Architecture
5. Using Plugins
6. Initializing a Jenkins Master
7. Projects / jobs
8. Freestyle UI jobs
9. CI/CD as Code: Pipeline Projects
10. Declarative versus Scripted pipelines
11. Views and folders
12. Managing credentials and secrets
13. Distributing workloads – Master and Agent nodes
14. Integrating with Git: Source Control Management
15. Triggers: Scheduled Polling and Webhooks
16. Notifications: Instant Messaging Integration
17. Requiring human input and approval
18. Automated code linting and testing
19. Jenkins Integration with managed nodes
20. Continuous deployment through Jenkins

Part 3: Code Deployment and Release Management

1. Java
   1. Building an artifact
   2. Storing Artifacts locally
2. Python
   1. Building an artifact
   2. Storing Artifacts locally

Part 4: Notifications with Slack

1. Integration setup
2. Using Slack for CI/CD notifications

Part 5: Linux Management