Week 3 Notes working through the AZ400 Ignite Cloud Challenge.

Introduction to source control

(State of DevOps Report 2021)[https://puppet.com/resources/report/2021-state-of-devops-report]

Version control is essential for all software development projects, it vital for companies where distributed teams, processes, organisation structure (siloed, hierarchical) all contribute to the project. Using version control manages challenges of co-ordination and integration for deploying and merging code. Practical way to ensure standards are met.

Source control allows for code collaboration and change tracking, essential for larger multi-developer projects. Snapshots of file changes allow for review and roll back if needed. Helps manage conflicts in changes / merges. Enables tracking of every change in software of who did what, when.

Whether for personal use or professional source control should be used.

• Create workflows: standardised tools, process and permissions enforcement.
• Versioning: can add description to specific versions, helps with identifying potential base to start from.
• Collaboration: helps resolves and prevent merge conflicts, even with simultaneous changes.
• History: change record, enables experimentation and rollback as needed.
• Automation: test, code analysis and deployment can be automated.

Code should follow the values:

• Reusability: reuse code, so don’t do same thing twice, makes things simpler.
• Traceability: Activities should be traced, easier debugging and root cause analysis.
• Manageability: enforce workflows, rules and quality gates.
• Efficiency: minimising time and effort, use the right resource for the job.
• Collaboration: working together improves quality.
• Learning: orgs benefit from investing in learning, especially around onboarding new employees.

Best practices for using source control:

• Small changes: commit early and often, but not unfinished work
• No personal files: omit application settings and SSH keys.
• Update often: minimises merge conflicts by updating often and before commits.
• Test code: test and compile code before commiting
• Watch for messages: commit message will report issues
• Follow conventions: be a team player, consistency is essential for quality, allows for the next person to pick up code quickly.

Describe types of source control systems

Centralized Source Control - central single copy of project. Check in changes to the central copy. Version control tool scan auotmatically update content of any changed filed. Changesets, group of changes (over many files) treated as a cohesive whole. Team Foundation Version Control (TFVC), Subversion (SVN), CVS or Perforce.

TFVC - Server or Local workspaces. Server, requires connection to server, locks workflows. Local copies codebase and works offline. Check in changes and resolve any conflicts.

Workflow Get latest changes from central store -> Make change and test -> Check-in change to main server for others to see

Distributed Source Control - Distributed Source Control / Version Control Systems (DVCS) have become more popular. Git, Mercurial and Bazaar. Don’t rely on central server to store all versions. Each developer has a local copy/clone. Sounds wasteful to have lots of copies but storage is cheap and modern file systems can compress files too. Pulling (Getting changes), Pushing (commiting your changes), move changesets not single file diffs. Can have a central authoritative copy if central repo needed, making it optional.

Pulling / Pushing changesets fast on local copy, and can be grouped together for single push at once. Local work possible, able to share changes for feedback. But, could take up large amounts of space if large number of binary files, also long time to sync if entire history is long and complex.

Git expect system for most new projects, very popular among open-source projects. Get a local working copy with history of commits, allows for comparisons and commits offline. Allows for easier scaling of team, not block fo main branches, if there is an issue everything still has a local copy to work from. Using feature branches means people have a starting point to use if things go wrong. Git branches are cheap and easy to merge, allowing for trunk based development. Each feature/change gets it’s own isolated environment, copied from main branch. Merge change back into main branch via Pull Request where validation and checks can be done by other developers or automation functions. Ultimate goal of systems like git is to speed up the release cycle, by promoting agile workflows by doing small and frequent changes and pipelines can run faster when compared to large monolithic releases. Works well with CI/CD

Issues using Git technically allows for history to be rewritten, addition feature can prevent this (eg Azure Repo prevents using “Force Push”). Git works better with smaller files. Large files can clog up machine, Git LFS created to solve this, large files stored separately but still benefit of versioning. Binary files cannot be optimized and should not be stored in git, package management like Azure Artifacts should be used instead.

Work with Azure Repos and GitHub

Azure Repos supports bit git distributed version control and TFVS centralised version control. Free private Git repos, works with any git client, webhooks and APIs, semantic search, collaboration, integration with Azure Pipelines, branch policies.

Github largest open-source community, host & review code, manage projects, provides web UI, CI/CD pipelines with GitHub Actions, security & vulnerabilities checks, code and documentations in one place, project management.

Migrating from TFVS to Git Usually does not make sense to migrate history is large restructure is happening. Create new repo, checkout latest code from TFS, reorg and the commit to Git. Single branch import is an option with TFVC and Azure DevOps, can migrate upto 180 days history too. If already in Azure DevOps and only care about a main branch then efficient way to migrate.

GIT-TFS can be used to migration more than a single branch, open-source project to sync Git and TFVC, but can be used for a single migration, can migrate multiple branches, preserving relationships, can take a long time depending on repo. GIT-SVN also available for Subversion syncing.

GitHub Codespaces - cloud-based development environment, basically VS Code, allows to work from browser even on tablets or chromebooks. Can also connect to codespace from local VS Code installation.

Structure your Git Repo

Git easy to start but difficult to master, many different ways to implement, code structure, branching and merging options, pull requests for reviews. Over time repos with bloat and artifacts and unrelated old code. 2 ways to organise repos

• Monorepo : all code in one place, simple to access and clone, 1 step and done
• Multiple repos : organising code into separate repos Best way depends on what will allow teams to go the fastest. Using multiple repos allows each team to use whatever libraries, tools and workflows they want for thier own project, issue is that not everything developed in a given repo, needs to be treated like a third-party library even if person next to you makes it. Bug fixing has extra steps as artifacts need to be published and consumed by other repos. Can increase the friction or wait time for teams to fix the issue. Single repo might be better but means a single large repo.

Change Log List of changes, can be posted on blog or to CHANGELOG.md file in repo, can be automated to manually created. (gitchangelog)[https://pypi.org/project/gitchangelog/] and (github-changelog-generator)[https://github.com/github-changelog-generator/github-changelog-generator] can generate log for you.

Manage Git branches and workflows

Consider size of team, easy of error correction, cognitive overhead when deciding on git workflow.

Trunk-based extension of centralised workflow, all feature development takes place on dedicated branches, this encapsulation easy for multiple developers to work on independent features, merging back to main when working, so branch should be clear on broken code.

Branch > Commits > Pull Request > Code Review > Deploy > Merge

Forking workflow each developer as a server-side repo, means each conntributor has two repos one private local and one public server-side.

Collaborate with pull requests in Azure Repos

Pull requests tell others about changes, so they can be reviewed. Commonly used in the shared repository models. Open source projects use PRs for managing contribution from maintainers.

Identify technical debt

Code quality can be measured by 5 traits

Reliability - probability a system will run without issue. Measured by mean time between failures (MTBF).

Maintainability - how easy the software can be maintained, codebase size, consistency, structure and complexity. Some metrics around stylistic warnings and Halstead complexity. Both automation and human review should be used to keep code maintainable.

Testability - how well the ocde supports testing. Relies on how you control, observe, isolate and automate the testing. measured by how many test cases. Code complexity can impact testing.

Portability - how the software runs in different environments. No specific measure. Test code on different plants, set compiler warnings high and using multiple types. Enforcing standards will help portability.

Reusability - whether assets / code can be used again. Modular code that is loosely coupled makes assets more reusable. Number of interdependencies can measure reusability. Static analyzer can help.

Complexity metrics are important for measuring quality, cyclomatic complexity, number of linearly independent paths. Halstead complexity measures Program vocabulary, Program length, Calculated program length, Volume, Difficulty, Effort.

Common Metrics

• Failed builds percentage
• Failed deployments percentage
• Ticket volume
• Bug bounce percentage : reopened bug percentage
• Unplanned work percentage

Technical Debt - future cost that will be incurred by choosing easy route today. More debt less time adding value, just reworking current code.

Common sources

• Lack of coding standard
• Poor design of unit test
• Not understanding design principles
• Monolithic classes and code
• Poor use of technology, architecture or approach
• Over-engineered code
• Insufficient documentation
• No self-documenting code
• Taking shortcuts
• Dead code left in place

SonarCloud can be added to Azure DevOps to analyse code, NDepend for .Net, ReSharper also available

Also plan effective code reviews.