changed: misc tidy ups

Author: aabouzaid

docs/content/module-04/README.md

@@ -156,15 +156,15 @@ description: "Review goals in planning, then apply the Twelve-Factor App methodo
 - [What is observability? - Grafana](https://grafana.com/docs/grafana-cloud/introduction/what-is-observability/)
 - [Logs vs Metrics vs Traces - Engineering Fundamentals Playbook](https://microsoft.github.io/code-with-engineering-playbook/observability/log-vs-metric-vs-trace/)
 - [The Three Pillars of Observability - Sematext](https://sematext.com/glossary/three-pillars-of-observability/)
-- [The Site Reliability Workbook -Chapter 4 - Monitoring](https://sre.google/workbook/monitoring/) 
+- [The Site Reliability Workbook -Chapter 4 - Monitoring](https://sre.google/workbook/monitoring/)
 
 ## 4.7 Continuous Delivery - Introduction and Solutions in the Market
 
 <img class="img-right" align="right" width="25%" src="/img/topics/continuous-delivery.png"></img>
 
 ### What you need to know {#47-what-you-need-to-know}
 
-- In simple words, `Continuous Delivery` is a practice where code changes are automatically prepared for release to multiple environments, especially production. This involves deploying all code changes to a testing environment and then to a production-like environment after passing automated tests, ensuring the software is always in a deployable state. 
+- In simple words, `Continuous Delivery` is a practice where code changes are automatically prepared for release to multiple environments, especially production. This involves deploying all code changes to a testing environment and then to a production-like environment after passing automated tests, ensuring the software is always in a deployable state.
 - Following CD practices allows teams to deliver new features and bug fixes more safely and quickly to users, reducing the risk of deployment errors.
 - It's important to know that `CD` could refer to two different things: `Continuous Delivery` and `Continuous Deployment`. They are usually used interchangeably, but in reality, they are two different stages.
 - In many cases, the same [Continuous Integration solutions](../module-03#36-continuous-integration---introduction-and-solutions-in-the-market) could be used for continuous delivery/deployment; however, there are specialized solutions that work best for CD.

docs/content/module-06/README.md

@@ -41,7 +41,7 @@ Finally, remember that retro is not only about bad things. It's also time to cel
 - First of all, avoid `premature optimization`! Optimizing code too early usually leads to unnecessary complex solutions and wastes a lot of time without a good return. At first, focus only on critical use cases, then optimize based on actual performance issues as you go.
 - If you know from the beginning that you need a high-performance solution, start with a programming language or a framework known for that. You will save a lot of effort if you select the correct tool early on. Also, follow the selected language's best practices for performance optimization.
 - A simple method for code performance optimization is `caching`. Use it whenever possible on all levels, like database caching, in-memory caching Valkey or Memcached as a caching layer, and even DNS caching, which could save you a lot of necessary calls (external caching could also be helpful, like using Content Delivery Network "CDN" to cache static content).
-- Following the same caching concept, try to minimize external API calls. The fastest request is the one that was never made! 
+- Following the same caching concept, try to minimize external API calls. The fastest request is the one that was never made!
 - Avoid dull operations like calling a function repeatedly that could be called once outside the loop. As a rule of thumb, any code that doesn't change between iterations should be outside the loop.
 - Finally, if you need to dive deeper and optimize your code (again, if necessary), profiling tools are your best friend.
 
@@ -144,14 +144,14 @@ Multi-environment setup is not a trivial topic, but like anything else, doing it
 
 - Before diving into Continuous Deployment, we need to have a look at Continuous Delivery end-to-end release automation, which is the process of producing products ready for deployment.
 - In fact, there are many types of release, but they could be narrowed down to two types: `Versioned release` and `Rolling release`.
-- In a versioned release, you release an artefact with a specific version, like `1.0.0`. [Semantic Versioning](https://semver.org/) is one of the most popular versioning styles, but it's not the only one. Users should deliberately upgrade to the new version if they need the latest updates. This type is common in application code, especially if you have external consumers. 
+- In a versioned release, you release an artefact with a specific version, like `1.0.0`. [Semantic Versioning](https://semver.org/) is one of the most popular versioning styles, but it's not the only one. Users should deliberately upgrade to the new version if they need the latest updates. This type is common in application code, especially if you have external consumers.
 - In rolling releases, you release an artifact with a marker like a Git hash or even a branch name, which works just as a reference or a pointer. The users will always get the latest updates at any point in time. This type is common in Infrastructure as Code, especially for internal use.
 - It's hard to say one is better than the other; each has pros and cons and recommended use cases.
 - In both styles, there are a couple of things you need to remember:
   - Release quality is the same as the CI pipeline quality. Follow [CI best practices](../module-04/#44-continuous-integration---ci-best-practices) and add all standard quality gates.
   - Everything should be done in version control. No magic should happen outside the Git repository.
   - Ensure that the artifact is in at least one environment for consumers before it goes out.
-  - Learn about Rollback and Rollforward strategies to deal 
+  - Learn about Rollback and Rollforward strategies to deal with failed releases.
   - Generate changelog or release notes based on the Git commits. [Conventional Commits](https://www.conventionalcommits.org/en/) is famous for applications, and [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) is common for IaC. There are many tools to automate that step regardless of the Git commit convention you use (e.g., [git-cliff](https://github.com/orhun/git-cliff)).
   - Automate the release chores and version bumps using tools like [release-please](https://github.com/googleapis/release-please) and [release-it](https://github.com/release-it/release-it).
   - For security, sign the artifacts using [Sigstore/Cosign](https://github.com/sigstore/cosign) using the effortless `keyless signing`.

docs/content/module-07/README.md

@@ -34,7 +34,7 @@ This project should follow the same MVP approach and work in phases and always r
 - Create a high-level project roadmap.
 - Identify the tech stack that will be used in the project.
 - Define a reasonable timeline for the project.
-- Make a simple risk assessment to spot the obstacles you know or don't know about. 
+- Make a simple risk assessment to spot the obstacles you know or don't know about.
 
 ## 7.3 Implementation
 

docs/content/next-steps/README.md

@@ -5,7 +5,7 @@ description: "You finished the roadmap, what should you do now?"
 
 [🗂 Back to the Roadmap Index](../../getting-started#roadmap-index)
 
-Now that you've finished the roadmap, what's next? There is good news and bad news! The good news is that finishing this roadmap should increase your chances in the market. The bad news is that the tech industry is always evolving super fast, and the DevOps domain evolves even faster! So there are no options but to keep going and always stay in shape! 
+Now that you've finished the roadmap, what's next? There is good news and bad news! The good news is that finishing this roadmap should increase your chances in the market. The bad news is that the tech industry is always evolving super fast, and the DevOps domain evolves even faster! So there are no options but to keep going and always stay in shape!
 
 It's time to face the real world and prepare for the next steps. We will cover some topics to help you step up and keep developing yourself.
 
@@ -50,8 +50,8 @@ It's time to face the real world and prepare for the next steps. We will cover s
 - The chart alone is not enough; always combine it with a one-page document that adds some context about your skills.
 - Use the chart as a high-level for your next steps and career development.
 - Update your skill chart at least once every year or, even better, every 6 months.
-- You can do this yourself, but it's highly recommended that you do it with someone close to you. 
-- Ask for feedback whenever possible. 
+- You can do this yourself, but it's highly recommended that you do it with someone close to you.
+- Ask for feedback whenever possible.
 - Always remember that ... you must be honest with yourself; otherwise, the whole process will be worthless!
 
 ## DevOps Certificates

docs/faq/README.md

@@ -97,7 +97,7 @@ Why not 100%? As the roadmap takes a pragmatic approach, the last 20% varies a l
 
 This roadmap is designed for a wide range of audiences, but each requires different efforts and risks. The risk here is archiving the final goal, finishing the roadmap, and being a qualified DevOps Engineer.
 
-Low risk means it's more likely the learner will reach the goal, and high risk means it's less likely the learner will reach the goal (the time here is a significant factor in this formula. As the time increases, there are more chances that the learner will divert from the goal). 
+Low risk means it's more likely the learner will reach the goal, and high risk means it's less likely the learner will reach the goal (the time here is a significant factor in this formula. As the time increases, there are more chances that the learner will divert from the goal).
 
 Audience groups:
 

docs/getting-started/README.md

@@ -31,7 +31,7 @@ How to process:
 
 In this mode, you already have some experience with DevOps (usually between 1-2 years of work experience). Still, you want to further your skills with a real hands-on industry-grad project to learn DevOps pragmatically. This mode is also available to everyone in this repo.
 
-The project follows the `Learning by Doing` method (aka `Problem-based Learning`), which is done in iterative phases. In this method, you learn as you go and cover the whole DevOps cycle. 
+The project follows the `Learning by Doing` method (aka `Problem-based Learning`), which is done in iterative phases. In this method, you learn as you go and cover the whole DevOps cycle.
 
 How to process:
 

docs/growth/_category_.yaml

@@ -6,4 +6,3 @@ collapsed: false
 link:
   type: generated-index
   description: You are now a DevOps Engineer, what are other advanced or promising career paths?
-  

docusaurus.config.ts

@@ -78,7 +78,7 @@ const config: Config = {
   ],
 
   themeConfig: {
-    image: 'img/dynamic-devops-roadmap-pillars.png',
+    image: 'img/dynamic-devops-roadmap-flow-regular-bg.png',
     navbar: {
       title: 'Dynamic DevOps Roadmap',
       logo: {