CI CD

🔴 CICD Definition ===>>
________________________________________________________________________________________________________________________________________________________
(CI) continuous integration, (CD) countinuos deployment and also (CD) continuous delivery is a process of software 
delivery by automating task like build, test and deploy.

🔘Countinuous Integration --
    1. Code Commit:  A developer makes changes to the codebase and commits them to a version control system (VCS) like Git.
    2. Code Checkout: The CI pipeline retrieves the latest committed code from the VCS repository.
    3. Build Stage: The code is compiled or assembled into a usable format
    4. Test Stages:
        o Unit tests (verify individual code units)
        o Integration tests (ensure different code parts work together)
        o Static code analysis (identifies potential issues without running code)

🔘Continuous Delivery --
    1. Leverage CI:
          CD relies on a well-established CI pipeline that performs automated builds, tests, and generates feedback for code changes.
    2. Code Promotion (Optional):
          After successful testing in the CI pipeline, the code might be promoted to a staging environment. 
          allowing for final testing and validation before pushing to live users.
    3. Automated Deployment:
          Upon successful completion of all stages (CI and potentially staging), the CD pipeline triggers an automated deployment process. 
          This involves packaging the approved code into a deployable artifact and sending it to the production environment.
    4. Environment Management:
          CD tools often manage deployments across different environments (staging, production, etc.). 
          They can automate configuration changes and ensure consistency between environments.
5. Approval Gates (Optional):
          In some CD pipelines, there might be manual approval gates before deploying to production. 
          This allows for human oversight and control over critical releases.
6. Monitoring and Rollbacks:
          After deployment, CD pipelines often integrate with monitoring tools to track the health and performance of the application in production.
          If issues arise, some CD pipelines can facilitate rollbacks to previous versions if necessary.

🔘continuous Deployment -- Automates the entire deployment process (Continuous Delivery), including pushing the code live to production.
------------------------------------------------------------------------------------------------------------------------------------------------------------

🔴 EXAMPLE ==>>
___________________________________________________________________________________________________________________________________________________________

                                   ___________________________________________________________________________________
                                                name: CICD
                                                
                                                on:
                                                  push:
                                                    branches: [main,master]
                                                    
                                                jobs:
                                                  build-and-deploy:
                                                    runs-on: [ubuntu-latest]
                                                    steps:
                                                      - name: Checkout Source
                                                        uses: actions/checkout@v3
                                                      - name: Configure AWS credentials
                                                        uses: aws-actions/configure-aws-credentials@v3
                                                        with:
                                                          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
                                                          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
                                                          aws-region: 'ap-south-1'
                                                      - name: Login to Amazon ECR
                                                        id: login-ecr
                                                        uses: aws-actions/amazon-ecr-login@v2
                                                
                                                      - name: Build, tag, and push image to Amazon ECR
                                                        id: build-image
                                                        env:
                                                          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
                                                          IMAGE_TAG: latest
                                                          ECR_REPOSITORY: nodejs-app
                                                        run: |
                                                          # Build a docker container and
                                                          # push it to ECR so that it can
                                                          # be deployed to ECS.
                                                          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
                                                          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
                                                          echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT
                                                      - name: Fill in the new image ID in the Amazon ECS task definition
                                                        id: task-def
                                                        uses: aws-actions/amazon-ecs-render-task-definition@v1
                                                        with:
                                                          task-definition: node-app-task.json
                                                          container-name: myCont
                                                          image: ${{ steps.build-image.outputs.image }}
                                                      - name: Deploy Amazon ECS task definition
                                                        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
                                                        with:
                                                          task-definition: ${{ steps.task-def.outputs.task-definition }}
                                                          service: node-app-service
                                                          cluster: nodejs-app-DEV
                                                          wait-for-service-stability: true
                               __________________________________________________________________________________________________

Explanation ===>>
                        Trigger:
                        
                        on: This section defines the event that triggers the pipeline workflow. In this case, the pipeline runs:
                        When there's a push to the main or master branch.
                        Job:
                        
                        jobs: This section defines a single job named build-and-deploy. This job performs all the build, image creation, and deployment tasks within the pipeline.
                        Job Steps:
                        
                        Checkout Source:
                        
                        This step uses the actions/checkout@v3 action to check out the source code from the GitHub repository.
                        Configure AWS Credentials:
                        
                        This step uses the aws-actions/configure-aws-credentials@v3 action to securely configure AWS credentials for the pipeline to interact with AWS services.
                        It retrieves the access key ID and secret access key from GitHub Secrets, which are secure environment variables stored within the repository.
                        Login to Amazon ECR:
                        
                        This step uses the aws-actions/amazon-ecr-login@v2 action to log in to the Amazon ECR (Elastic Container Registry) where the Docker image will be stored.
                        Build, Tag, and Push Image to Amazon ECR:
                        
                        This step performs the following actions:
                        Builds a Docker image using the docker build command.
                        Sets environment variables for the image tag (latest), ECR registry URI (ECR_REGISTRY), and ECR repository name (ECR_REPOSITORY). These variables are used within the command.
                        Pushes the built image to the specified ECR repository using docker push.
                        Saves the image URI (including registry, repository, and tag) in a GitHub output variable named image for later use.
                        Fill in the New Image ID in the Amazon ECS Task Definition:
                        
                        This step uses the aws-actions/amazon-ecs-render-task-definition@v1 action to update an existing ECS task definition file (node-app-task.json).
                        It replaces a placeholder for the container image (image) with the actual image URI retrieved from the previous step ({{ steps.build-image.outputs.image }}).
                        This ensures the task definition references the newly built and pushed image.
                        Deploy Amazon ECS Task Definition:
                        
                        This step uses the aws-actions/amazon-ecs-deploy-task-definition@v1 action to deploy the updated ECS task definition.
                        It specifies the following details:
                        task-definition: The path to the updated task definition file ({{ steps.task-def.outputs.task-definition }}).
                        service: The name of the ECS service that needs to be updated with the new task definition (node-app-service).
                        cluster: The name of the ECS cluster where the service is running (nodejs-app-DEV).
                        wait-for-service-stability: This option (set to true) ensures the pipeline waits for the ECS service to stabilize after the deployment before finishing.
                        Overall Functionality:
                        
                        When a push occurs to the main or master branch, the pipeline triggers.
                        The pipeline retrieves AWS credentials securely and logs in to ECR.
                        It builds a Docker image, pushes it to ECR, and updates the ECS task definition with the new image URI.
                        Finally, it deploys the updated task definition to the specified ECS service, ensuring a smooth update process.


================================🔴🔴🔴Intervew Questions🔴🔴🔴===================================

1. What are the core principles of CI/CD?
    1. Automation:
    2. Continuous Integration:    
    3. Fast Feedback:
    4. Short Feedback Loops:
    5. Version Control Integration:
    6. Infrastructure as Code (IaC):
    7. Repeatability and Reliability:
    8. Security:
    9. Monitoring:
    10. Continuous Improvement

2. Explain the benefits of implementing a CI/CD pipeline.
    1. Increased Efficiency and Speed
    2. Improved Software Quality
    3. Enhanced Reliability and Consistency
    4. Reduced Risk and Easier Rollbacks
    5. Improved Collaboration and Communication

3. How does CI/CD differ from DevOps?
    In essence, CI/CD is a core set of practices within the broader DevOps philosophy. 
    DevOps leverages CI/CD automation but also emphasizes cultural change, communication, 
    and continuous improvement throughout the entire software development lifecycle.

4. Describe the trade-offs between continuous deployment and feature flag releases.
    🔘Use CD for: Low-risk updates, bug fixes, and features with minimal impact on core functionality.
    🔘Use FFR for: Critical features, features requiring A/B testing, or situations where you need to 
                 control the rollout process for better risk management.

    A Hybrid Approach:

    Many teams adopt a hybrid approach, combining CD with FFRs. You can leverage CD for low-risk deployments 
    and utilize FFRs for critical features or those requiring controlled rollouts.

5. What are some challenges you've faced in implementing CI/CD pipelines, and how did you overcome them?
    Challenge 1: Complex Dependencies
    Challenge 2: Monitoring and Alerting

6. Compare and contrast popular CI/CD tools like Jenkins, Azure DevOps, and GitHub Actions. 
    Feature	                Jenkins	            Azure DevOps	    GitHub Actions
    Pricing	                Free (Open Source)	Paid Subscription	Free (Public Repos)
    Deployment Model	    Self-Hosted	        Cloud-Based	        Cloud-Based
    Ease of Use	            Moderate	        Easy	            Easy
    Customization	        Extensive	        Moderate	        Moderate
    Community and Support	Large and Active	Good	            Good (GitHub Community)
    Integration with VCS	Flexible	        Good (Azure Repos)	Excellent (GitHub)
    Focus	                Customizable	    Continuous Delivery	CI/CD for Developers

7. Explain your experience with containerization technologies like Docker and Kubernetes. 

8. How would you leverage infrastructure as code (IaC) tools like Terraform or AWS CloudFormation in your CI/CD pipeline?
    1. Infrastructure Definition
    2. Integration with CI/CD Pipeline
    3. Pipeline Stages:

        🔘Pre-build (Optional): In this stage, you can leverage Terraform to provision temporary infrastructure for testing 
           or development purposes. This allows developers to test their application in a simulated production environment.
        🔘Build: This stage typically focuses on building your application code.
        🔘Test: In this stage, you can use Terraform to provision testing environments where your built application can be 
           deployed and thoroughly tested.
        🔘Deploy: This is where Terraform shines. Terraform commands can be used to:
        🔘Provision production infrastructure: Terraform can automatically create the necessary resources (servers, databases, etc.) 
           in your production environment based on your configuration files.
        🔘Deploy application code: After infrastructure provisioning, you can use deployment tools within your pipeline to deploy 
           the built application code onto the newly created infrastructure.
        🔘Update infrastructure (Optional): If your application requires infrastructure changes, Terraform's "apply" command can 
           be used to update the infrastructure in your production environment to match the desired state defined in your configuration files.