re-factor ci/cd

docs/CI-CD/continuous-delivery.md

@@ -139,7 +139,7 @@ Try to limit the number of versions of your application running parallel in prod
 
 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](low-code-solutions/README.md).
+Here is a guide for [continuous deployment for Low Code Solutions](recipes/cd-on-low-code-solutions.md).
 
 ## References
 

docs/CI-CD/continuous-integration.md

@@ -45,7 +45,7 @@ An automated build should encompass the following principles:
 
 - Code across an engineering team must be formatted to agreed coding standards. Such standards keep code consistent, and most importantly easy for the team and customer(s) to read and refactor. Code styling consistency encourages collective ownership for project scrum teams and our partners.
 - There are several open source code style validation tools available to choose from ([code style checks](https://github.com/checkstyle/checkstyle), [StyleCop](https://en.wikipedia.org/wiki/StyleCop)). The [Code Review recipes section](../code-reviews/recipes/README.md) of the playbook has suggestions for linters and preferred styles for a number of languages.
-- Your code and documentation should avoid the use of non-inclusive language wherever possible. Follow the [Inclusive Linting section](inclusive-linting.md) to ensure your project promotes an inclusive work environment for both the team and for customers.
+- Your code and documentation should avoid the use of non-inclusive language wherever possible. Follow the [Inclusive Linting section](recipes/inclusive-linting.md) to ensure your project promotes an inclusive work environment for both the team and for customers.
 - We recommend incorporating security analysis tools within the build stage of your pipeline such as: code credential scanner, security risk detection, static analysis, etc. For Azure DevOps, you can add a security scan task to your pipeline by installing the [Microsoft Security Code Analysis Extension](https://secdevtools.azurewebsites.net/#pills-onboard). GitHub Actions supports a similar extension with the [RIPS security scan solution](https://github.com/marketplace/actions/rips-security-scan).
 - Code standards are maintained within a single configuration file. There should be a step in your build pipeline that asserts code in the latest commit conforms to the known style definition.
 

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

@@ -16,6 +16,6 @@ Topics covered:
 1. [Credential Scanning](./secret-management/credential_scanning.md) - automatically inspecting a project to ensure that no secrets are included in the project's source code.
 1. [Secrets Rotation](./secret-management/secrets_rotation.md) - automated process by which the secret, used by the application, is refreshed and replaced by a new secret.
 1. [Static Code Analysis](./secret-management/static-code-analysis.md) - analyze source code or compiled versions of code to help find security flaws.
-1. [Penetration Testing](./penetration-testing/README.md) - a simulated attack against your application to check for exploitable vulnerabilities.
-1. [Container Dependencies Scanning](./dependency-container-scanning/README.md) - search for vulnerabilities in container operating systems, language packages and application dependencies.
-1. [Evaluation of Open Source Libraries](./evaluate-oss/README.md) - make it harder to apply open source supply chain attacks by evaluating the libraries you use.
+1. [Penetration Testing](./penetration-testing.md) - a simulated attack against your application to check for exploitable vulnerabilities.
+1. [Container Dependencies Scanning](./dependency-and-container-scanning.md) - search for vulnerabilities in container operating systems, language packages and application dependencies.
+1. [Evaluation of Open Source Libraries](./evaluate-open-source-software.md) - make it harder to apply open source supply chain attacks by evaluating the libraries you use.

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

@@ -39,10 +39,10 @@ steps:
 
 YAML pipelines can be triggered without the need for a pull request, this introduces a security risk.
 
-In good practice, [Pull Requests](../../../code-reviews/pull-requests.md) and [Code Reviews](../../../code-reviews/README.md) should be used to ensure the code that is being deployed, is being reviewed by a second person and potentially automatically being checked for vulnerabilities and other security issues.
+In good practice, [Pull Requests](../../code-reviews/pull-requests.md) and Code Reviews should be used to ensure the code that is being deployed, is being reviewed by a second person and potentially automatically being checked for vulnerabilities and other security issues.
 However, YAML Pipelines can be executed without the need for a Pull Request and Code Reviews. This allows the (malicious) user to make changes using the Service Connection which would normally require a reviewer.
 
-The configuration of *when* a pipeline should be triggered is specified in the YAML Pipeline itself and therefore a pipeline can be configured to execute on changes in a temporary branch. In this temporary branch, any changes made to the pipeline itself will be executed without being reviewed.  
+The configuration of *when* a pipeline should be triggered is specified in the YAML Pipeline itself and therefore a pipeline can be configured to execute on changes in a temporary branch. In this temporary branch, any changes made to the pipeline itself will be executed without being reviewed.
 
 If the given pipeline has been granted [Pipeline-level permissions](https://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints#pipeline-permissions) to use a specific Service Connection, any command can be executed using that Service Connection, without anyone reviewing the command.
 Since Service Connections can have a lot of permissions in the external service, executing any pipeline without review could potentially have big consequences.

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

@@ -1,12 +1,24 @@
-# Secrets Management
+# Secrets management
 
-Secrets Management refers to the way in which we protect configuration settings and other sensitive data which, if
-made public, would allow unauthorized access to resources. Examples of secrets are usernames, passwords, api keys, SAS
-tokens etc.
+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.
 
 We should assume any repo we work on may go public at any time and protect our secrets, even if
 the repo is initially private.
 
+## Importance of Secrets Management
+
+In modern software development, applications often need to interact with other software components, APIs, and services. These interactions often require authentication, which is typically handled using secrets. If these secrets are not managed properly, they can be exposed, leading to potential security breaches.
+
+## Best Practices for Secrets Management
+
+1. **Centralized Secret Storage:** Store all secrets in a centralized, encrypted location. This reduces the risk of secrets being lost or exposed.
+1. **Access Control:** Implement strict access control policies. Only authorized entities should have access to secrets.
+1. **Rotation of Secrets:** Regularly change secrets to reduce the risk if a secret is compromised.
+1. **Audit Trails:** Keep a record of when and who accessed which secret. This can help in identifying suspicious activities.
+1. **Automated Secret Management:** Automate the processes of secret creation, rotation, and deletion. This reduces the risk of human error.
+
+Remember, the goal of secret management is to protect sensitive information from unauthorized access and potential security threats.
+
 ## General Approach
 
 The general approach is to keep secrets in separate configuration files that are not checked in
@@ -53,7 +65,7 @@ These techniques make the loading of secrets  transparent to the developer.
 For .NET SDK (version 2.0 or higher) we have `dotnet secrets`, a tool provided by the .NET SDK that allows you to manage and protect sensitive information, such as API keys, connection strings, and other secrets, during development. The secrets are stored securely on your machine and can be accessed by your .NET applications.
 
 ```shell
-# Initialize dotnet secret 
+# Initialize dotnet secret
 dotnet user-secrets init
 
 # Adding secret
@@ -176,4 +188,4 @@ The following steps lay out a clear pathway to creating new secrets and then uti
 
 ### Validation
 
-Automated credential scanning can be performed on the code regardless of the programming language. Read more about it [here](../../continuous-integration/dev-sec-ops/secret-management/credential_scanning.md)
+Automated [credential scanning](credential_scanning.md) can be performed on the code regardless of the programming language.

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

@@ -6,7 +6,7 @@ Credential scanning is the practice of automatically inspecting a project to ens
 
 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.
- As such, there should be a clear boundary between code and secrets: secrets should be managed outside of the source code (read more [here](../../../continuous-delivery/secrets-management/README.md)) and credential scanning should be employed to ensure that this boundary is never violated.
+As such, there should be a clear boundary between code and secrets: secrets should be managed outside of the source code and credential scanning should be employed to ensure that this boundary is never violated.
 
 ## Applying Credential Scanning
 

docs/README.md

@@ -9,19 +9,15 @@ An engineer working for a [ISE](ISE.md) project...
 
 This is our playbook. All contributions are welcome! Please feel free to submit a pull request to get involved.
 
-## Why Have A Playbook
+## Why have a Playbook
 
 * To increase overall efficiency for team members and the whole team in general.
 * To reduce the number of mistakes and avoid common pitfalls.
 * To strive to be better engineers and learn from other people's shared experience.
 
-## "The" Checklist
+If you do nothing else follow the [Engineering Fundamentals Checklist](./engineering-fundamentals-checklist.md)!
 
-If you do nothing else follow the [Engineering Fundamentals Checklist](ENG-FUNDAMENTALS-CHECKLIST.md)!
-
-## Structure of a Sprint
-
-The [structure of a sprint](SPRINT-STRUCTURE.md) is a breakdown of the sections of the playbook according to the structure of an Agile sprint.
+The [first week of an ISE project](./the-first-week-of-an-ise-project.md) is a breakdown of the sections of the playbook according to the structure of an Agile sprint.
 
 ## General Guidance
 
@@ -36,34 +32,6 @@ The [structure of a sprint](SPRINT-STRUCTURE.md) is a breakdown of the sections
 * 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
-
-* [Engineering Fundamentals Checklist](ENG-FUNDAMENTALS-CHECKLIST.md)
-* [Structure of a Sprint](SPRINT-STRUCTURE.md)
-
-## Engineering Fundamentals
-
-* [Accessibility](accessibility/README.md)
-* [Agile Development](agile-development/README.md)
-* [Automated Testing](automated-testing/README.md)
-* [Code Reviews](code-reviews/README.md)
-* [Continuous Delivery (CD)](continuous-delivery/README.md)
-* [Continuous Integration (CI)](continuous-integration/README.md)
-* [Design](design/readme.md)
-* [Developer Experience](developer-experience/README.md)
-* [Documentation](documentation/README.md)
-* [Engineering Feedback](engineering-feedback/README.md)
-* [Observability](observability/README.md)
-* [Security](security/README.md)
-* [Privacy](privacy/README.md)
-* [Source Control](source-control/README.md)
-* [Reliability](reliability/README.md)
-
-## Fundamentals for Specific Technology Areas
-
-* [Machine Learning Fundamentals](machine-learning/README.md)
-* [User-Interface Engineering](user-interface-engineering/README.md)
-
 ## Contributing
 
 See [CONTRIBUTING.md](https://github.com/microsoft/code-with-engineering-playbook/tree/master/CONTRIBUTING.md) for contribution guidelines.

docs/engineering-fundamentals-checklist.md

@@ -10,7 +10,7 @@ This checklist helps to ensure that our projects meet our Engineering Fundamenta
 - [ ] Commit history is consistent and commit messages are informative (what, why).
 - [ ] Consistent branch naming conventions.
 - [ ] Clear documentation of repository structure.
-- [ ] Secrets are not part of the commit history or made public. (see [Credential scanning](continuous-integration/dev-sec-ops/secret-management/credential_scanning.md))
+- [ ] Secrets are not part of the commit history or made public. (see [Credential scanning](ci-cd/dev-sec-ops/secrets-management/credential_scanning.md))
 - [ ] Public repositories follow the [OSS guidelines](source-control/README.md#creating-a-new-repository), see `Required files in default branch for public repositories`.
 
 More details on [source control](source-control/README.md)
@@ -35,7 +35,7 @@ More details on [automated testing](automated-testing/README.md)
 - [ ] Project uses CD to manage deployments to a replica environment before PRs are merged.
 - [ ] Main branch is always shippable.
 
-More details on [continuous integration](continuous-integration/README.md) and [continuous delivery](continuous-delivery/README.md)
+More details on [continuous integration](ci-cd/continuous-integration.md) and [continuous delivery](ci-cd/continuous-delivery.md)
 
 ## Security
 

docs/the-first-week-of-an-ise-project.md

@@ -34,13 +34,13 @@ The purpose of this document is to:
   - Agree on how to separate unit tests from integration, load and smoke tests
   - Design the first test cases
 - [ ] [Decide on branch naming](source-control/naming-branches.md)
-- [ ] [Discuss security needs and verify that secrets are kept out of source control](continuous-delivery/gitops/secret-management/azure-devops-secret-management-per-branch.md)
+- [ ] [Discuss security needs and verify that secrets are kept out of source control](ci-cd/dev-sec-ops/secrets-management/)
 
 ## Day 2
 
 - [ ] [Set up Source Control](source-control/README.md)
   - Agree on [best practices for commits](source-control/git-guidance/README.md#commit-best-practices)
-- [ ] [Set up basic Continuous Integration with linters and automated tests](continuous-integration/README.md)
+- [ ] [Set up basic Continuous Integration with linters and automated tests](ci-cd/continuous-integration.md)
 - [ ] [Set up meetings for Daily Stand-ups and decide on a Process Lead](agile-development/basics/ceremonies.md#stand-up)
   - Discuss purpose, goals, participants and facilitation guidance
   - Discuss timing, and how to run an efficient stand-up
@@ -55,7 +55,7 @@ The purpose of this document is to:
 
 ## Day 4
 
-- [ ] [Set up Continuous Deployment](continuous-delivery/README.md)
+- [ ] [Set up Continuous Deployment](ci-cd/continuous-delivery.md)
   - Determine what environments are appropriate for this solution
   - For each environment discuss purpose, when deployment should trigger, pre-deployment approvers, sing-off for promotion.
 - [ ] [Decide on a versioning strategy](source-control/component-versioning.md)