AZ-400 Designing and Implementing Microsoft DevOps Solutions Exam

Design and implement a strategy for managing large files, including Git Large File Storage and git-fat

Large files can slow down repository performance and increase storage costs. Git Large File Storage (LFS) and git-fat are tools that help manage these files by storing them outside the normal Git history. Using these tools means you keep only small pointers in the main repository, making everyday operations faster and more efficient.

Git LFS replaces large files with lightweight pointers and stores the actual content on a separate server. git-fat works similarly by syncing specified files to external storage services. Both tools:

• Track file changes using pointer references
• Store actual content outside the Git tree
• Speed up clone and fetch operations

When setting up a large file strategy, remember to add patterns to a .gitattributes file. This ensures Git automatically directs large files to the chosen storage. It’s important to review which files need LFS or git-fat to avoid adding every large asset by mistake.

Regularly monitor your repository size and update tracking rules as projects evolve. Encourage team members to pull LFS or git-fat settings on clone, so everyone uses the same configuration. Keeping large files out of the standard history helps maintain a clean and responsive repository.

Design a strategy for scaling and optimizing a Git repository, including Scalar and cross-repository sharing

As projects grow, Git repositories can become hard to manage, leading to slow clones and high disk use. Scalar is a Microsoft tool designed to optimize large repos by improving fetch and clone performance. It adds features like sparse checkout, cache servers, and remote optimizations to keep huge codebases efficient.

Cross-repository sharing shares common code across multiple repositories without duplication. You can use:

• Git submodules to link separate repositories as subfolders
• Git subtree to merge another repo into a subdirectory while preserving history
• Package managers to distribute shared libraries separately

Combining Scalar with sharing strategies helps teams work on huge codebases without long waits. Key improvements include shorter clone times and reduced local storage needs. This mix of tools and practices ensures that repositories stay nimble as they scale.

Plan regular cleanup of unnecessary files and branches to keep repo health in check. Educate developers on how to use Scalar commands and share code responsibly. A well-optimized repository supports faster development cycles and better collaboration.

Configure permissions in the source control repository

Securing your code starts with setting the right permissions in Azure Repos. You can control access at both the repository and branch level, ensuring only authorized team members can push or approve changes. Implementing branch policies helps enforce quality gates before code merges.

Azure Repos permissions include:

• Read: View code and history
• Contribute: Push commits and create branches
• Branch-specific policies: Require pull request reviews, enforce build success

Apply the principle of least privilege by giving each user or group only the rights they need. Use Azure Active Directory groups to manage permissions at scale and audit changes through the built-in logs. Consistent reviews of permission settings help maintain a secure environment.

Document and communicate your permission model so everyone knows their responsibilities. Automate enforcement by using branch policies and pull request requirements. This approach ensures that code changes are reviewed, tested, and compliant with team standards.

Configure tags to organize the source control repository

Tags are a simple way to mark important points in your repository history, such as releases or milestones. There are two main types of tags: lightweight and annotated. Lightweight tags are quick bookmarks, while annotated tags store metadata like the author, date, and message.

Creating and using tags involves:

• git tag v1.0.0 to create a lightweight tag
• git tag -a v1.0.0 -m "Release version 1.0.0" to create an annotated tag
• git push origin --tags to share tags with the remote repository

Use semantic versioning (e.g., MAJOR.MINOR.PATCH) to keep tag names clear and consistent. Underlining naming conventions and tag descriptions helps teams quickly identify versions. Annotated tags are recommended for released builds because they include richer information.

Review and prune old tags periodically to avoid clutter. Encourage developers to follow the tagging strategy in your team’s documentation. Well-organized tags make it easier to roll back, audit, and track releases over time.

Recover specific data by using Git commands

Mistakes happen, but Git provides several tools to recover lost or deleted data. The git reflog command tracks updates to the HEAD, making it possible to find commits that might seem lost. Once you locate the right commit ID, you can restore files or branches safely.

Key recovery commands include:

• git reflog to list recent HEAD moves
• git checkout <commit-id> -- <filename> to restore a file from a past commit
• git cherry-pick <commit-id> to apply a specific commit onto the current branch

Use these commands carefully and create a new branch when restoring data to avoid overwriting current work. Underlines the importance of working on a separate branch until you confirm the recovery is successful. This practice keeps the main branch clean and stable.

Regular backups and proper branching strategies complement recovery tools. Teach your team to check the reflog before trying more complex fixes. This approach ensures minimal data loss and quick restoration of important work.

Remove specific data from source control

Sometimes you need to purge sensitive or large data from your repository history. Tools like git filter-branch or the BFG Repo-Cleaner help rewrite history to remove unwanted files. This process rewrites commits, so it requires caution and coordination with your team.

Steps for safe data removal:

• Clone the repository with --mirror to get all refs
• Use git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <file>" --prune-empty --tag-name-filter cat -- --all
• Run bfg --delete-files <filename> for a simpler interface with BFG Repo-Cleaner
• Force-push the cleaned history with git push --force --all

Always inform collaborators before rewriting history, as they’ll need to re-clone or reset their local copies. Underlines that force pushes can disrupt workflows if not communicated properly. After cleanup, verify that the data is gone by checking the remote repository.

Maintain a backup of the original repository until you are confident the cleanup succeeded. Clear guidelines and communication are essential to avoiding confusion and lost work during history rewrites.

Conclusion

In this section, students learned how to manage repositories by handling large files with Git LFS and git-fat, ensuring smooth performance. We explored scaling strategies using Scalar and cross-repository techniques to keep massive codebases nimble. Securing the repository with proper permissions and enforcing branch policies helps protect your code from unauthorized changes.

Organizing code history through clear tags makes releases and rollbacks straightforward. When errors occur, commands like git reflog and cherry-pick allow precise data recovery without major disruptions. Finally, removing unwanted or sensitive data with filter-branch or BFG Repo-Cleaner keeps your repository clean and compliant.

Together, these practices form a solid foundation for configuring and managing Git repositories in Azure DevOps. By applying these strategies, teams can maintain high performance, security, and organization as their projects grow.