49:54
Day-3 | Branching Strategy & CI Rules | 30 Days Of GitLab DevOps
DevOps Shack
Overview
This video introduces essential DevOps concepts for GitLab, focusing on branching strategies, branch protection, and CI/CD pipeline rules. It explains two primary branching strategies: Git Flow and Trunk-Based Development, detailing their structures, benefits, and use cases. The session also covers the importance of branch protection to maintain code integrity, especially for production branches, and demonstrates how to configure these rules in GitLab. Finally, it delves into setting up CI/CD pipeline rules to control when specific stages, like deployment, are triggered based on branch changes, using feature flags as a key enabler for Trunk-Based Development.
How was this?
Save this permanently with flashcards, quizzes, and AI chat
Chapters
- GitLab pipelines are triggered by Git actions, not on a schedule, making branching strategy crucial for pipeline behavior.
- Branching strategy dictates when pipelines run, what stages execute (e.g., testing vs. deployment), and whether code is deployed.
- A poor branching strategy can lead to unintended deployments, merge conflicts, and production instability.
- Proper branching ensures only tested and approved code reaches production, preventing critical failures.
Understanding how your branching strategy directly influences your CI/CD pipeline's execution is fundamental to building reliable and automated software delivery processes.
A half-finished feature being accidentally deployed because there's no clear strategy for which branches are production-ready.
- Git Flow uses multiple dedicated branches for different development phases: main (production), develop (integration), feature branches (new development), release branches (testing/staging), and hotfix branches (urgent production fixes).
- Feature branches isolate development of single features, merging back into 'develop' after completion.
- Release branches are created from 'develop' for final testing and bug fixing before merging into 'main' for production deployment.
- Hotfix branches are created directly from 'main' to address critical production bugs quickly, merging back into both 'main' and 'develop'.
Git Flow provides a structured approach to managing complex development cycles with distinct phases for feature development, release preparation, and urgent fixes, ensuring stability.
Creating a 'feature/feedback-page' branch from 'develop' to build a new feedback form, keeping it separate from ongoing development until it's ready.
- Trunk-Based Development primarily uses a single 'main' branch (the trunk) for all development.
- Features are broken down into smaller, independently deployable units, developed on short-lived branches that merge back to 'main' frequently (daily or more).
- Feature flags are essential to control the visibility of unfinished or newly deployed features, allowing continuous integration without impacting users.
- This strategy enables rapid iteration, easier rollbacks (by disabling feature flags), and simpler pipeline management.
Trunk-Based Development, coupled with feature flags, allows for faster delivery cycles and safer deployments by integrating code frequently and controlling feature release independently.
Netflix developing a new homepage where only 20% is complete; the incomplete feature is merged to 'main' but hidden from users via a feature flag until all parts are ready and deployed.
- Branch protection prevents direct pushes to critical branches like 'main', ensuring code quality.
- Rules can enforce that changes must go through merge requests (pull requests) with reviews.
- Settings can require successful pipeline runs and code approvals from a specified number of reviewers before merging.
- Force pushes are typically disallowed on protected branches to maintain a clear commit history.
Protecting your main branch is a critical safeguard against introducing bugs or unstable code into your production environment, ensuring a higher level of reliability.
Configuring GitLab so that no one can push directly to the 'master' branch; all changes must be submitted via a merge request, reviewed, and approved before being merged.
- CI/CD rules in GitLab allow granular control over when specific jobs or stages execute.
- Rules can be defined based on the commit branch, commit message, or other pipeline variables.
- For example, a 'deploy' job can be configured to run only when commits are made to the 'main' or 'master' branch.
- This ensures that CI stages (like build and test) run on all branches, while CD stages (like deployment) are restricted to production-ready branches.
Implementing CI/CD rules ensures that your automated pipelines perform the correct actions (like testing or deploying) only in the appropriate environments and under the right conditions.
Setting up a rule so that the 'deploy to production' job in the `gitlab-ci.yml` file only runs when changes are pushed to the 'master' branch, not on feature branches.
Key takeaways
- Branching strategies are foundational to CI/CD, directly impacting pipeline execution and deployment safety.
- Git Flow offers a structured, multi-branch approach suitable for projects with distinct release cycles.
- Trunk-Based Development prioritizes frequent integration and uses feature flags for flexible feature release and rollback.
- Branch protection is essential for maintaining the integrity of production branches by enforcing review and approval workflows.
- CI/CD rules allow precise control over pipeline job execution based on specific conditions, such as the target branch.
- Feature flags are a powerful tool in Trunk-Based Development, decoupling code deployment from feature release.
- Understanding and implementing these concepts is key to efficient and reliable DevOps practices.
Key terms
Branching StrategyGit FlowTrunk-Based DevelopmentMain BranchDevelop BranchFeature BranchRelease BranchHotfix BranchMerge Request (Pull Request)Branch ProtectionCI/CD RulesFeature FlagsCI Commit BranchGitLab CI/CD Pipeline
Test your understanding
- How does a branching strategy influence the behavior of GitLab CI/CD pipelines?
- What are the primary differences between Git Flow and Trunk-Based Development, and when might you choose one over the other?
- Why is branch protection crucial for a production branch like 'main' or 'master'?
- How can feature flags be used to manage the release of new features in a Trunk-Based Development workflow?
- What is the purpose of CI/CD rules, and how can they be configured to control job execution based on the commit branch?