Adding CD docs

docs/ci-cd/continuous-delivery.md

@@ -0,0 +1,52 @@
+---
+sidebar_position: 2
+---
+
+# Continuous Delivery
+
+Continuous Delivery (CD) extends the concept of Continuous Integration (CI) by ensuring that software can be released to production at any time in a safe, quick, and sustainable manner. CD automates the delivery of applications to selected infrastructure environments, enabling teams to build, test, and release software with greater speed and efficiency. This practice is fundamental in supporting a DevOps culture by minimizing the manual steps involved in deploying applications, thus reducing the risk associated with human error.
+
+## Key Concepts and Terminology
+
+- **Deployment Pipeline**: A sequence of stages through which software must pass before it is released. Each stage validates the software through automated builds, tests, and deployment processes.
+- **Release Automation**: The process of automating the steps required to deploy a software application to production or staging environments.
+- **Artifact Repository**: A storage location for build artifacts that have passed through the initial stages of the Continuous Integration process, ready for deployment.
+- **Environment**: A runtime context where applications are deployed, such as development, testing, staging, and production environments.
+
+## The CD Process
+
+Continuous Delivery involves several key steps, building upon the foundation laid by Continuous Integration:
+
+1. **Code Commit**: Similar to CI, the process begins when developers commit code changes to the version control repository.
+2. **CI Process**: Changes trigger the CI pipeline, where the application is built, and automated tests are run to verify functionality and performance.
+3. **Artifact Generation**: Successful builds generate artifacts, which are versions of the software that can be deployed to any environment.
+4. **Automated Deployment**: Artifacts are automatically deployed to a staging or testing environment where automated and manual tests can be conducted.
+5. **Approval for Release**: Once the application passes all checks in the staging environment, it awaits approval for release to production. This step can be automated or manual, depending on the organization's policies.
+6. **Release to Production**: Approved changes are deployed to the production environment. This step can be fully automated or require manual intervention for final verification.
+7. **Monitoring and Feedback**: After deployment, continuous monitoring ensures the application performs as expected. Feedback loops provide insights into the deployment process and application performance, informing future development.
+
+## Best Practices
+
+Implementing Continuous Delivery effectively involves adhering to several best practices:
+
+**Automate Everything**: Automate not just the build and testing processes, but also deployment, monitoring, and feedback loops.
+**Environment Consistency**: Ensure all environments (development, testing, staging, production) are as similar as possible to avoid unexpected behavior during deployments.
+**Deploy Frequently**: Regular, small deployments reduce risks, making it easier to identify and address issues quickly.
+**Rollback Strategy**: Have a clear, automated strategy for rolling back deployments in case of failure.
+**Decouple Deployment from Release**: Deploying code to production does not mean releasing it to users. Use feature flags to enable new features when ready.
+**Collaboration and Communication**: Foster a culture of open communication and collaboration between development, operations, and other stakeholders.
+**Continuous Improvement**: Regularly review and improve the deployment process, tooling, and practices based on feedback and performance metrics.
+
+## CD Tools
+
+Several tools and platforms support Continuous Delivery, providing features for automating the deployment process, managing infrastructure, and monitoring application performance. Some popular CD tools include:
+
+- **Jenkins**: An open-source automation server that supports building, deploying, and automating any project.
+- **GitLab CI**: A part of GitLab's DevOps platform that provides continuous integration and continuous delivery.
+- **GitHub Actions**: A CI/CD service provided by GitHub that allows you to automate your workflow directly from your repository.
+- **ArgoCD**: A declarative, GitOps continuous delivery tool for Kubernetes.
+- **Flux**: A GitOps operator for Kubernetes that ensures the state of your cluster matches the configuration in your Git repository.
+
+## Conclusion
+
+Continuous Delivery enables organizations to release new changes to customers quickly and sustainably. By automating the build, test, and deployment processes, CD reduces the risks associated with manual deployments, improves product quality, and accelerates the delivery of value to customers. Adopting CD practices requires commitment to automation, process improvement, and collaboration across development and operations teams.

docs/ci-cd/delivery-vs-deployment.md

@@ -0,0 +1,33 @@
+---
+sidebar_position: 3
+---
+
+# Continuous Delivery vs. Continuous Deployment
+
+Continuous Deployment and Continuous Delivery are two closely related practices in the realm of automated software release processes, often part of a broader DevOps approach. While they share similarities and the same initials (CD), they cater to slightly different stages of the software release pipeline and embody different philosophies regarding the automation of software releases. Here are the main differences between the two:
+
+## Continuous Delivery
+
+- **Goal**: The primary goal of Continuous Delivery is to ensure that the software can be reliably released to production at any time. It extends Continuous Integration by deploying all code changes to a testing environment and/or a production-like staging environment after the build stage. This practice enables a team to ensure that the software is always in a deployable state.
+
+- **Manual Release Trigger**: Continuous Delivery often includes a manual step for deployment to production. The decision to deploy is made by the team, based on business requirements, schedules, or other considerations. This manual gate before production deployment allows for final verification, stakeholder approval, or scheduling the release at an optimal time.
+
+- **Focus**: Focuses on automating the testing and deployment processes up to, but not always including, the final step of deploying to production. Continuous Delivery ensures that every change is deployable and that there is a clear, automated pathway to production, even if the final step requires human intervention.
+
+## Continuous Deployment
+
+- **Goal**: Continuous Deployment takes Continuous Delivery one step further by automating the deployment to production. With this practice, every change that passes through the pipeline's automated tests is deployed to production automatically, without explicit approval for each specific deployment.
+
+- **Automated Release Trigger**: The deployment process in Continuous Deployment is fully automated. If a change passes all stages of the pipeline (build, test, and any pre-production verification), it gets released to production automatically. There's no manual intervention required for a deployment to happen.
+
+- **Focus**: Focuses on minimizing the time and effort required to get changes released to users. Continuous Deployment aims to accelerate the feedback loop with customers by ensuring that any code commit that meets the automated quality checks is released to customers without delay.
+
+## Summary of Differences
+
+- **Manual vs. Automated Deployment**: The most significant difference lies in how deployments to production are triggered. Continuous Delivery allows for manual control over the timing of releases, while Continuous Deployment automates this step entirely.
+
+- **Approach to Releases**: Continuous Delivery provides flexibility in scheduling and vetting releases, making it suitable for businesses that require control over when changes are made live. Continuous Deployment suits organizations aiming for maximum efficiency and speed in delivering changes to users, assuming their testing and monitoring practices are robust enough to catch issues before and after deployment.
+
+- **Risk Management**: Continuous Deployment assumes a high level of confidence in the deployment pipeline's testing and monitoring capabilities, as any change could potentially be released to users automatically. Continuous Delivery allows for an additional layer of decision-making before changes go live, offering a balance between rapid iteration and risk management.
+
+Both practices require a strong foundation in Continuous Integration and automated testing to work effectively. The choice between Continuous Delivery and Continuous Deployment often comes down to the organization's risk tolerance, regulatory requirements, and business needs.