Scaling Git for Enterprise DevOps
0 likes868 views
This document discusses several Git strategies for scaling source code management in large enterprises, including using mono vs multi repositories, Git hooks, Git versioning, and public projects. It provides advantages of different repository structures, examples of Git hooks, an overview of Git Version for semantic versioning, and differences between public and private projects in Azure DevOps.
Scaling Git for Enterprise DevOps
- 1. Scaling Git for Enterprise DevOps Eng Teong Cheah Microsoft MVP for Developer Technologies
- 2. How to Structure Your Git Repo
- 3. Mono vs Multi Repos Advantages • Clear ownership • Better scale • Narrow clones • Better developer testing • Reduced code complexity • Effective code reviews • Sharing of common components • Easy refactoring Mono-repo - source code is kept in a single repository Multiple-repo – each project has its own repository
- 4. Git Hooks
- 5. Git Hooks Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. Git hooks are built-in feature – no need to download anything. Git hooks are run locally.
- 6. Git Hooks These hook scripts are only limited by a developer’s imagination. Some example hook scripts include: - pre-commit: Check the commit message for spelling errors - pre-receive: Enforce project coding standards - post-commit: Email/SMS team members of a new commit - post-receive: Push the code to production
- 7. Git Version
- 8. Git Version Git Version is a tool to help you achieve Semantic Versioning on your project.
- 9. Version sources There are a number of sources Git Version can get its versions from, they include: - Tags - Version numbers in branches - Merge messages - Track version of another branch - GitVersion.yml file
- 10. Public Projects
- 11. Public Projects An Azure DevOps Services public project provides support to share code with others and to support continuous integration/continuous deployment (CI/CD) of open source software. Users aren’t required to sign in to gain read-only access to many of the services.
- 12. Public versus private projects Projects in Azure DevOps provide a repository for source code and a place for a group of developers and teams to plan, tack progress, and collaborate on building software solutions. One or more projects can be defined within an organization in Azure DevOps. Users that aren’t signed into the service have read-only access to public projects on Azure DevOps. Private projects, on the other hand, require users to be granted access to the projects and signed in to access the services.
- 13. Supported services Non-members of a public project have read-only access to a limited access to a limited set of services, specifically: - Browse the code base, download code, view commits, branches, and pull requests - View and filter work items - View a project page or dashboard - View the project Wiki - Perform semantic search of the code or work items
- 14. Demo: Azure Repos Collaborating with Pull Requests