fix title case on headings

README.md

@@ -38,7 +38,7 @@ A [breakdown of sections](docs/SPRINT-STRUCTURE.md) according to the structure o
 * Report product issues found and provide clear and repeatable engineering feedback!
 * We all own our code and each one of us has an obligation to make all parts of the solution great.
 
-## QuickLinks
+## Resources
 
 * [Engineering Fundamentals Checklist](docs/ENG-FUNDAMENTALS-CHECKLIST.md)
 * [Structure of a Sprint](docs/SPRINT-STRUCTURE.md)

docs/CI-CD/README.md

@@ -22,7 +22,7 @@ For a much deeper understanding of all of these concepts, the books [Continuous
 - We want the latest version of the code to always be deployed to our dev/test environments
 - We want a reliable release strategy, where the policies for release are well understood by all
 
-## The fundamentals
+## The Fundamentals
 
 - We run a quality pipeline (with linting, unit tests etc.) on each PR/update of the main branch
 - All cloud resources (including secrets and permissions) are provisioned through infrastructure as code templates – ex. Terraform, Bicep (ARM), Pulumi etc.

docs/CI-CD/continuous-delivery.md

@@ -49,15 +49,15 @@ Code changes released into the *test* environment typically targets the main bra
 
 The very first deployment of any application should be showcased to the customer in a production-like environment (*UAT*) to solicit feedback early. The UAT environment is used to obtain product owner sign-off acceptance to ultimately promote the release to production.
 
-#### Criteria for a production-like environment
+#### Criteria for a Production-Like Environment
 
 * Runs the same operating system as production.
 * Has the same software installed as production.
 * Is sized and configured the same way as production.
 * Mirrors production's networking topology.
 * Simulated production-like load tests are executed following a release to surface any latency or throughput degradation.
 
-#### Modeling your Release Pipeline
+#### Modeling Your Release Pipeline
 
 It's critical to model your test and release process to establish a common understanding between the application engineers and customer stakeholders. Specifically aligning expectations for how many cloud environments need to be pre-provisioned as well as defining sign-off gate roles and responsibilities.
 
@@ -85,7 +85,7 @@ The stages within your release workflow are ultimately testing a version of your
 
 A release should be running for a period of time before it's considered live and allowed to accept user traffic. These *warm up* activities may include application server(s) and database(s) pre-fill any dependent cache(s) as well as establish all service connections (eg *connection pool allocations, etc*).
 
-#### Pre-production releases
+#### Pre-production Releases
 
 Application release candidates should be deployed to a staging environment similar to production for carrying out final manual/automated tests (*including capacity testing*). Your production and staging / pre-prod cloud environments should be setup at the beginning of your project.
 
@@ -135,13 +135,13 @@ Canary releases simplify rollbacks as you can avoid routing users to bad applica
 
 Try to limit the number of versions of your application running parallel in production, as it can complicate maintenance and monitoring controls.
 
-### Low code solutions
+### Low Code Solutions
 
 Low code solutions have increased their participation in the applications and processes and because of that it is required that a proper conjunction of disciplines improve their development.
 
 Here is a guide for [continuous deployment for Low Code Solutions](recipes/cd-on-low-code-solutions.md).
 
-## References
+## Resources
 
 * [Continuous Delivery](https://www.continuousdelivery.com/) by Jez Humble, David Farley.
 * [Continuous integration vs. continuous delivery vs. continuous deployment](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment)

docs/CI-CD/continuous-integration.md

@@ -25,7 +25,7 @@ A robust build automation pipeline will:
 
 ## Build Definition Managed in Git
 
-### Code / manifest artifacts required to build your project should be maintained in within your project(s) git repository(s)
+### Code / Manifest Artifacts Required to Build Your Project Should be Maintained Within Your Projects Git Repository
 
 - CI provider-specific build pipeline definition(s) should reside within your project(s) git repository(s).
 
@@ -57,21 +57,21 @@ An automated build should encompass the following principles:
 
 - It's essential to have a build that's runnable through standalone scripts and not dependent on a particular IDE. Build pipeline targets can be triggered locally on their desktops through their IDE of choice. The build process should maintain enough flexibility to run within a CI server as well. As an example, dockerizing your build process offers this level of flexibility as VSCode and IntelliJ supports [docker plugin](https://code.visualstudio.com/docs/containers/overview) extensions.
 
-### DevOps security checks
+### DevOps Security Checks
 
 - Introduce security to your project at early stages. Follow the [DevSecOps section](dev-sec-ops/README.md) to introduce security practices, automation, tools and frameworks as part of the CI.
 
 ## Build Environment Dependencies
 
-### Automated local environment setup
+### Automated Local Environment Setup
 
 - We encourage maintaining a consistent developer experience for all team members. There should be a central automated manifest / process that streamlines the installation and setup of any software dependencies. This way developers can replicate the same build environment locally as the one running on a CI server.
 - Build automation scripts often require specific software packages and version pre-installed within the runtime environment of the OS. This presents some challenges as build processes typically version lock these dependencies.
 - All developers on the team should be able to emulate the build environment from their local desktop regardless of their OS.
 - For projects using VS Code, leveraging [Dev Containers](../developer-experience/devcontainers.md) can really help standardize the local developer experience across the team.
 - Well established software packaging tools like Docker, Maven, npm, etc should be considered when designing your build automation tool chain.
 
-### Document local setup
+### Document Local Setup
 
 - The setup process for setting up a local build environment should be well documented and easy for developers to follow.
 
@@ -183,16 +183,16 @@ The schema has 30+ [validators](https://json-schema.org/implementations.html#val
 
 An effective way to identify bugs in your build at a rapid pace is to invest early into a reliable suite of automated tests that validate the baseline functionality of the system:
 
-### End to end integration tests
+### End-to-End Integration Tests
 
 - Include tests in your pipeline to validate the build candidate conforms to automated business functionality assertions. Any bugs or broken code should be reported in the test results including the failed test and relevant stack trace. All tests should be invoked through a single command.
 - Keep the build fast. Consider automated test runtime when deciding to pull in dependencies like databases, external services and mock data loading into your test harness. Slow builds often become a bottleneck for dev teams when parallel builds on a CI server are not an option. Consider adding max timeout limits for lengthy validations to fail fast and maintain high velocity across the team.
 
-### Avoid checking in broken builds
+### Avoid Checking in Broken Builds
 
 - Automated build checks, tests, lint runs, etc should be validated locally before committing your changes to the scm repo. [Test Driven Development](https://martinfowler.com/bliki/TestDrivenDevelopment.html) is a practice dev crews should consider to help identify bugs and failures as early as possible within the development lifecycle.
 
-### Reporting build failures
+### Reporting Build Failures
 
 - If the build step happens to fail then the build pipeline run status should be reported as failed including relevant logs and stack traces.
 
@@ -206,22 +206,22 @@ An effective way to identify bugs in your build at a rapid pace is to invest ear
 
 ## Git Driven Workflow
 
-### Build on commit
+### Build on Commit
 
 - Every commit to the baseline repository should trigger the CI pipeline to create a new build candidate.
 - Build artifact(s) are built, packaged, validated and deployed continuously into a non-production environment per commit. Each commit against the repository results into a CI run which checks out the sources onto the integration machine, initiates a build, and notifies the committer of the result of the build.
 
-### Avoid commenting out failing tests
+### Avoid Commenting Out Failing Tests
 
 - Avoid commenting out tests in the mainline branch. By commenting out tests, we get an incorrect indication of the status of the build.
 
-### Branch policy enforcement
+### Branch Policy Enforcement
 
 - Protected [branch policies](https://help.github.com/en/github/administering-a-repository/about-protected-branches) should be setup on the main branch to ensure that CI stage(s) have passed prior to starting a code review. Code review approvers will only start reviewing a pull request once the CI pipeline run passes for the latest pushed git commit.
 - Broken builds should block pull request reviews.
 - Prevent commits directly into main branch.
 
-### Branch strategy
+### Branch Strategy
 
 - Release branches should auto trigger the deployment of a build artifact to its target cloud environment. You can find additional guidance on the Azure DevOps documentation site under the [Manage deployments](https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops#manage-deployments) section
 
@@ -231,7 +231,7 @@ An effective way to identify bugs in your build at a rapid pace is to invest ear
 
 In the spirit of transparency and embracing frequent communication across a dev crew, we encourage developers to commit code on a daily cadence. This approach provides visibility to feature progress and accelerates pair programming across the team. Here are some principles to consider:
 
-### Everyone commits to the git repository each day
+### Everyone Commits to the Git Repository Each Day
 
 - End of day checked-in code should contain unit tests at the minimum.
 - Run the build locally before checking in to avoid CI pipeline failure saturation. You should verify what caused the error, and try to solve it as soon as possible instead of committing your code. We encourage developers to follow a [lean SDLC principles](https://leankit.com/learn/lean/principles-of-lean-development/).
@@ -241,19 +241,19 @@ In the spirit of transparency and embracing frequent communication across a dev
 
 One of the key goals of build validation is to isolate and identify failures in staging environment(s) and minimize any disruption to live production traffic. Our E2E automated tests should run in an environment which mimics our production environment(as much as possible). This includes consistent software versions, OS, test data volume simulations, network traffic parity with production, etc.
 
-### Test in a clone of production
+### Test in a Clone of Production
 
 - The production environment should be duplicated into a staging environment(QA and/or Pre-Prod) at a minimum.
 
-### Pull request update(s) trigger staged releases
+### Pull Request Updates Trigger Staged Releases
 
 - New commits related to a pull request should trigger a build / release into an integration environment. The production environment should be fully isolated from this process.
 
-### Promote infrastructure changes across fixed environments
+### Promote Infrastructure Changes Across Fixed Environments
 
 - Infrastructure as code changes should be tested in an integration environment and promoted to all staging environment(s) then migrated to production with zero downtime for system users.
 
-### Testing in production
+### Testing in Production
 
 - There are various [approaches](https://medium.com/@copyconstruct/testing-in-production-the-safe-way-18ca102d0ef1) with safely carrying out automated tests for production deployments. Some of these may include:
   - Feature flagging
@@ -264,28 +264,28 @@ One of the key goals of build validation is to isolate and identify failures in
 
 Our devops workflow should enable developers to get, install and run the latest system executable. Release executable(s) should be auto generated as part of our CI/CD pipeline(s).
 
-### Developers can access latest executable
+### Developers can Access the Latest Executable
 
 - The latest system executable is available for all developers on the team. There should be a well-known place where developers can reference the release artifact.
 
-### Release artifact is published for each pull request or merges into main branch
+### Release Artifacts are Published for Each Pull Request or Merges into the Main Branch
 
 ## Integration Observability
 
 Applied state changes to the mainline build should be made available and communicated across the team. Centralizing logs and status(s) from build and release pipeline failures are essential for developers investigating broken builds.
 
 We recommend integrating Teams or Slack with CI/CD pipeline runs which helps keep the team continuously plugged into failures and build candidate status(s).
 
-### Continuous integration top level dashboard
+### Continuous Integration Top Level Dashboard
 
 - Modern CI providers have the capability to consolidate and report build status(s) within a given dashboard.
 - Your CI dashboard should be able to correlate a build failure with a git commit.
 
-### Build status badge in project readme
+### Build Status Badge in the Project Readme
 
 - There should be a build status badge included in the root README of the project.
 
-### Build notifications
+### Build Notifications
 
 - Your CI process should be configured to send notifications to messaging platforms like Teams / Slack once the build completes. We recommend creating a separate channel to help consolidate and isolate these notifications.
 

docs/CI-CD/dev-sec-ops/README.md

@@ -1,6 +1,6 @@
 # DevSecOps
 
-## The concept of DevSecOps
+## The Concept of DevSecOps
 
 DevSecOps or DevOps security is about introducing security earlier in the life cycle of application development (a.k.a shift-left), thus minimizing the impact of vulnerabilities and bringing security closer to development team.
 

docs/CI-CD/dev-sec-ops/azure-devops-service-connection-security.md

@@ -35,7 +35,7 @@ steps:
       }
 ```
 
-## Pipeline Security caveat
+## Pipeline Security Caveat
 
 YAML pipelines can be triggered without the need for a pull request, this introduces a security risk.
 

docs/CI-CD/dev-sec-ops/secrets-management/README.md

@@ -1,4 +1,4 @@
-# Secrets management
+# Secrets Management
 
 Secret management refers to the tools and practices used to manage digital authentication credentials (like API keys, tokens, passwords, and certificates). These secrets are used to protect access to sensitive data and services, making their management critical for security.
 

docs/CI-CD/dev-sec-ops/secrets-management/credential_scanning.md

@@ -2,7 +2,7 @@
 
 Credential scanning is the practice of automatically inspecting a project to ensure that no secrets are included in the project's source code. Secrets include database passwords, storage connection strings, admin logins, service principals, etc.
 
-## Why Credential scanning
+## Why Credential Scanning
 
 Including secrets in a project's source code is a significant risk, as it might make those secrets available to unwanted parties. Even if it seems that the source code is accessible to the same people who are privy to the secrets, this situation is likely to change as the project grows. Spreading secrets in different places makes them harder to manage, access control, and revoke efficiently. Secrets that are committed to source control are also harder to discard of, since they will persist in the source's history.
 Another consideration is that coupling the project's code to its infrastructure and deployment specifics is limiting and considered a bad practice. From a software design perspective, the code should be independent of the runtime configuration that will be used to run it, and that runtime configuration includes secrets.

docs/CI-CD/dev-sec-ops/secrets-management/recipes/detect-secrets-ado.md

@@ -1,4 +1,4 @@
-# Running detect-secrets in Azure DevOps Pipelines
+# Running `detect-secrets` in Azure DevOps Pipelines
 
 ## Overview
 

docs/CI-CD/dev-sec-ops/secrets-management/recipes/detect-secrets.md

@@ -1,4 +1,4 @@
-# Credential Scanning Tool: detect-secrets
+# Credential Scanning Tool: `detect-secrets`
 
 ## Background
 
@@ -28,7 +28,7 @@ python3 -m pip install detect-secrets
 detect-secrets scan > .secrets.baseline
 ```
 
-## Pre-commit hook
+## Pre-Commit Hook
 
 It is recommended to use `detect-secrets` in your development environment as a Git pre-commit hook.
 
@@ -45,7 +45,7 @@ repos:
         args: ['--baseline', '.secrets.baseline']
 ```
 
-## Usage in CI pipelines
+## Usage in CI Pipelines
 
 ```sh
 # backup the list of known secrets

docs/CI-CD/gitops/deploying-with-gitops.md

@@ -19,7 +19,7 @@ Some popular GitOps frameworks for Kubernetes backed by [CNCF](https://landscape
 - [Argo CD](https://argo-cd.readthedocs.io/en/stable/)
 - [Rancher Fleet](https://fleet.rancher.io/)
 
-## Deploying using GitOps
+## Deploying Using GitOps
 
 GitOps with Flux v2 can be enabled in Azure Kubernetes Service (AKS) managed clusters or Azure Arc-enabled Kubernetes connected clusters as a cluster extension. After the microsoft.flux cluster extension is installed, you can create one or more fluxConfigurations resources that sync your Git repository sources to the cluster and reconcile the cluster to the desired state. With GitOps, you can use your Git repository as the source of truth for cluster configuration and application deployment.
 

docs/CI-CD/gitops/github-workflows.md

@@ -4,7 +4,7 @@ A workflow is a configurable automated process made up of one or more jobs where
 
 Additional information on GitHub actions and GitHub Workflows in the links posted in the [references](#references) section below.
 
-## Workflow Per Environment
+## Workflow per Environment
 
 The general approach is to have one pipeline, where the code is built, tested and deployed, and the artifact is then promoted to the next environment, eventually to be deployed into production.
 
@@ -16,7 +16,7 @@ One way to get around the complexity of a single workflow is to have separate wo
 
 ![Workflow-Designs-Independent-Workflows](images/Workflow-Designs-Independent-Workflows.png)
 
-## References
+## Resources
 
 - [GitHub Actions](https://docs.github.com/en/actions)
 - [GitHub Workflows](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions)