Simple CICD In Devops

How It Works

1. Trigger : When a developer pushes code to the main branch, the pipeline starts.
2. Build and Test :
   • The code is checked out.
   • Dependencies are installed using npm install.
   • Tests are run using npm test.
3. Deploy to Staging :
   • If tests pass, the application is deployed to the staging environment.
4. Deploy to Production :
   • For Continuous Delivery, a manual approval step is added.
   • After approval, the application is deployed to production.

Let’s consider a real-time example of a web application development team building an e-commerce platform.

Scenario:

1. The team uses GitHub as their version control system.
2. They have a staging environment for testing and a production environment for live users.
3. They want to automate the process of building, testing, and deploying their application whenever new code is pushed to the repository.

1. Developer Commits Code

• A developer writes new code (e.g., adding a "shopping cart" feature) and pushes it to the GitHub repository.
• The push triggers the CI/CD pipeline.

2. Continuous Integration (CI)

• Automated Build :
  • The CI tool (e.g., Jenkins, GitHub Actions, GitLab CI/CD) pulls the latest code from the repository.
  • It builds the application (e.g., compiles code, installs dependencies).
• Automated Testing :
  • Runs unit tests, integration tests, and end-to-end tests to ensure the new code does not break existing functionality.
  • If any test fails, the pipeline stops, and the developer is notified to fix the issue.

3. Continuous Deployment/Delivery (CD)

• Staging Environment :
  • If all tests pass, the application is deployed to a staging environment.
  • The QA team or automated tools perform additional testing (e.g., user acceptance testing).
• Production Environment :
  • For Continuous Deployment: The application is automatically deployed to production if staging tests pass.
  • For Continuous Delivery: A manual approval step is required before deploying to production.

Sample CI/CD Pipeline Using GitHub Actions

Below is an example of a GitHub Actions workflow for a Node.js application:

File: .github/workflows/ci-cd.yml

name: CI/CD Pipeline

on:
  push:
    branches:
      - main # Trigger the pipeline on pushes to the main branch

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      # Step 1: Checkout the code
      - name: Checkout code
        uses: actions/checkout@v3

      # Step 2: Install dependencies
      - name: Install dependencies
        run: npm install

      # Step 3: Run tests
      - name: Run tests
        run: npm test

  deploy-to-staging:
    needs: build-and-test # This job runs only if the previous job succeeds
    runs-on: ubuntu-latest
    steps:
      # Step 4: Deploy to staging
      - name: Deploy to Staging
        run: echo "Deploying to Staging Environment"

  deploy-to-production:
    needs: deploy-to-staging # This job runs only if the staging deployment succeeds
    runs-on: ubuntu-latest
    steps:
      # Step 5: Manual Approval (for Continuous Delivery)
      - name: Manual Approval
        run: echo "Waiting for manual approval to deploy to Production"
      
      # Step 6: Deploy to production
      - name: Deploy to Production
        run: echo "Deploying to Production Environment"

@ Eliana Blake,

   Theory i know , can share some workable  example 

Certainly! Continuous Integration/Continuous Deployment (CICD) in DevOps is a software development practice that aims to automate the building, testing, and deployment of code changes. This automation helps development teams deliver high-quality software more frequently and reliably.

Here's a breakdown of the CICD process with a simple example:

1. Continuous Integration (CI):

- Developers regularly merge their code changes into a shared repository.

- Automated builds and tests are triggered upon each code commit to ensure that the new code integrates properly with the existing codebase.

- For example, every time a developer pushes their code changes to the repository, a CI tool like Jenkins or GitLab CI automatically kicks off a build process to compile the code and run tests.

2. Continuous Deployment (CD):

- Once the code passes all automated tests in the CI phase, it moves on to the deployment stage.

- In Continuous Deployment, the validated code changes are automatically deployed to production or staging environments.

- For instance, after all tests pass during the CI phase, the CD pipeline (using tools like Ansible, Kubernetes, or Docker) automatically deploys the application to the production server.

Sample Scenario:

- Let's consider a scenario where a team of developers is working on a web application. They use Git as their version control system.

- Whenever a developer pushes new code to the main branch, the CI/CD pipeline is triggered.

- The CI process kicks in, compiling the code, running unit tests, and generating artifacts.

- If everything checks out, the CD process takes over, deploying the new changes to a staging environment for further testing.

- Once the changes are validated in the staging environment, the CD pipeline can automatically promote the changes to the production environment, ensuring a seamless and efficient deployment process.

By implementing CICD practices, teams can achieve faster development cycles, reduced manual errors, and overall improved software quality. It automates repetitive tasks, streamlines the development process, and ultimately leads to quicker and more reliable software delivery.

I hope this explanation gives you a clear understanding of Simple CICD in DevOps. If you have any more specific questions or need further clarification, feel free to ask!