DEV Community

Cover image for # DevOps
Charles Otugeh
Charles Otugeh

Posted on

# DevOps

#devops

Who Cleans the Code? My Journey from DevOps Confusion to Building a Secure CI/CD Pipeline. 

Starting a career in DevOps is like drinking water from a fire-hose. You are hit with an overwhelming number of tools, frameworks, and acronyms.When I first started, I found myself stuck on a fundamental question: Who is actually responsible for code quality? Is it **Quality Assurance (QA)**, or is it **DevOps?** 

I spent a week spinning my wheels trying to figure out where the boundaries lie. Thankfully, during my training at Cyber Shujaa, they brought in a mentor working as a DevSecOps engineer at Sirianu Ltd. That single mentorship session cleared up my confusion and completely changed how I look at software delivery. Here is what I learned, how I resolved the QA vs. DevOps debate, and how I built my very first secure GitHub Actions pipeline with nodes.
Enter fullscreen mode Exit fullscreen mode 
The Big Debate: QA vs. DevOps vs. DevSecOpsIn traditional software teams, silos created a lot of back-and-forth shuffling:Developers wrote the code.QA engineers tested it for functional bugs. DevOps engineers deployed it. If something broke, everyone blamed each other. My mentor helped me realize that DevOps changes this dynamic entirely through automation. DevOps engineers do not manually check code quality. Instead, they build the infrastructure and automated pipelines that allow code to test itself. When you inject security into this mix, it becomes DevSecOps. Security is no longer an afterthought checked right before deployment; it is baked into every single phase of the development lifecycle.
Enter fullscreen mode Exit fullscreen mode

Phase 1: Streamlining Collaboration with Git Workflows. 

Every great pipeline starts with version control. You cannot automate code quality if your team is stepping on each other's toes in Git. The first milestone for my project team was setting up a centralized repository and enforcing a strict Git workflow (like Gitflow or Feature Branching). [Feature Branch] ──> [Pull Request + Automated Checks] ──> [Main Branch]

Why this matters: Unblocks Teams: Developers can work on features independently without breaking the main code-base. Standardizes Quality: By protecting the main branch, we ensure no code gets merged without passing predefined criteria.
Enter fullscreen mode Exit fullscreen mode

Phase 2: Shifting Left with Pre-Commit Hooks. 

One of the most valuable lessons I learned from my Sirianu Ltd mentor was the concept of "shifting left." This means catching security vulnerabilities and code defects as early as possible in the development process—ideally, right on the developer's local machine before the code ever reaches GitHub. To achieve this, we configured pre-commit hooks.Guarding Against the OWASP Top 10. Pre-commit hooks act as a local gatekeeper. When a developer types git commit, the hooks run automatically to scan the code. If the scan fails, the commit is blocked. This is a massive milestone for a DevSecOps engineer because it addresses critical security risks highlighted in the OWASP Top 10, such as: Identification and Authentication Failures: Scanning for hardcoded API keys, database passwords, or AWS secrets before they are pushed to a public repository.Security Misconfigurations: Detecting poorly configured Dockerfiles or open ports early.
Enter fullscreen mode Exit fullscreen mode

Phase 3: Building the GitHub Actions CI/CD Pipeline. 

Once the code passes local checks and is pushed to GitHub, the Continuous Integration (CI) pipeline takes over. We used GitHub Actions to automate this entire process.The primary goal of our CI/CD setup is to guarantee that zero bugs and security vulnerabilities find their way into the "production chamber."
Enter fullscreen mode Exit fullscreen mode 
name: CI/CD Security Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  lint-and-audit:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Run Code Quality Linter
        run: |
          # Example: Using Flake8 for Python or ESLint for JavaScript
          npm run lint 

      - name: Security Vulnerability Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
Enter fullscreen mode Exit fullscreen mode

Automated Security Alerts 

If a developer pushes code that violates our quality standards or introduces a vulnerable dependency, the pipeline fails. GitHub Actions is configured to immediately trigger notifications (via email or Slack alerts). This feedback loop ensures developers know exactly what broke and how to fix it immediately.

### Phase 4: Containerization, Health Checks, and Sprint 1 Closure
Enter fullscreen mode Exit fullscreen mode

Once the code checks out, we transition to the deployment preparation phase. For our team's first sprint, we focused on core user infrastructure: Registration and Login endpoints. Here is how we verified and deployed the application:

 ## Dockerization
Enter fullscreen mode Exit fullscreen mode

We wrote a Dockerfile to package our application into an isolated container environment. We built the Docker image directly inside our pipeline to ensure environmental consistency.

docker build -t my-app:latest .
Enter fullscreen mode Exit fullscreen mode

Integration and Health Testing 

A container running in isolation doesn't mean much if it cannot talk to its dependencies. We spun up our application alongside a database container (like PostgreSQL or MongoDB) using Docker Compose to test end-to-end functionality.Database Health Checks: We implemented a retry script to ensure the database was fully up, initialized, and accepting connections before starting the app.Endpoint Validation: We ran automated integration tests against our registration and login routes to verify that user tokens were properly generated and security protocols worked.
``
3. Deployment With all health checks passing, the final step of the pipeline was deployment. We pushed our verified containers to our hosting environment container runners like Render to make the live endpoints accessible.
Enter fullscreen mode Exit fullscreen mode

Final Thoughts: 

The DevOps MindsetLooking back at my first week, I realize that DevOps isn't just about knowing how to write a YAML pipeline or build a Docker image. It is about cultivating a culture of shared responsibility both technical and Soft skills are required. Thanks to the team at Cyber Shujaa and the guidance from our DevSecOps mentor, I no longer wonder whose job it is to check code quality. It is the pipeline's job—and it is our job to build it securely.
Enter fullscreen mode Exit fullscreen mode

Top comments (0)