DEV Community

Cover image for An Industry Standard Summary for SDLC of a Three-tier Microservice Architecture with CI-CD Stages.
Giri Dharan
Giri Dharan

Posted on

An Industry Standard Summary for SDLC of a Three-tier Microservice Architecture with CI-CD Stages.

#devops #cicd #microservices #softwaredevelopment

Part 1: Stages of the Software Development Lifecycle (SDLC)

The SDLC provides the overarching framework for the project, from idea to decommissioning. Here are its core stages, tailored for a large-scale project like an NBN application.

1. Project Planning & Ideation

  • Objective: Define the project's scope, goals, feasibility, and high-level plan.
  • Key Activities for NBN:
    • Stakeholder Alignment: Engage with NBN Co, government bodies, retail service providers (RSPs), and end-users to understand business needs (e.g., a new customer portal, a field technician app, or a network monitoring system).
    • Feasibility Study: Technical feasibility (can we build it?), economic (what's the ROI?), operational (can we support it?), and legal (compliance with Australian telecommunications regulations).
    • Resource Planning: Estimate team size (developers, architects, QA), tools, and budget.
    • Timeline & Milestones: Create a high-level roadmap using methodologies like Agile (Scrum/Kanban) for flexibility.
    • Risk Assessment: Identify initial risks (e.g., changing regulations, network infrastructure delays, cybersecurity threats).

2. Requirements Gathering & Analysis

  • Objective: Translate business needs into detailed, actionable functional and non-functional requirements.
  • Key Activities for NBN:
    • Functional Requirements: "The system must allow a user to check their eligible NBN plans by entering their address." "The system must allow a technician to update the status of a installation job."
    • Non-Functional Requirements (CRITICAL for NBN):
      • Performance: System must handle 10,000 concurrent users during peak sign-up periods.
      • Scalability: Must scale horizontally to handle future growth in users and connected premises.
      • Availability: 99.99% uptime (four nines) for critical services.
      • Security: Must comply with the Australian Information Security Manual (ISM) and protect personally identifiable information (PII). Penetration testing is mandatory.
      • Data Residency: Certain customer data might be required to reside onshore in Australia.

3. Design & Architecture

  • Objective: Create the technical blueprint for the system.
  • Key Activities for NBN:
    • System Architecture: Defining the three-tier microservices architecture (detailed in Part 3).
    • UI/UX Design: Creating wireframes and prototypes for user interfaces (e.g., customer self-service portal).
    • Data Design: Designing database schemas (SQL for consistency, NoSQL for scalability), data flow diagrams, and caching strategies (Redis).
    • API Design: Defining clear contracts for APIs between microservices (using OpenAPI/Swagger).

4. Development (Implementation)

  • Objective: Write the code according to the design specifications.
  • Key Activities for NBN:
    • Setting Up Repos: Using a Git-based system (e.g., GitHub, GitLab) with a branching strategy like Trunk-Based Development or GitFlow.
    • Coding Standards: Enforcing standards and using linters.
    • Microservices Development: Teams work in parallel on different services (e.g., one team on "User Authentication," another on "Service Qualification").
    • Infrastructure as Code (IaC): Writing code (Terraform, CloudFormation) to define the cloud environment (AWS, Azure, GCP).

5. Testing

  • Objective: Verify that the software meets all requirements and is bug-free.
  • Key Activities for NBN:
    • Unit Testing: Developers test individual functions/modules.
    • Integration Testing: Testing interactions between microservices.
    • Performance/Load Testing: Simulating high traffic to ensure the system meets NBN's scalability demands.
    • Security Testing: SAST, DAST, and regular penetration testing.
    • UAT (User Acceptance Testing): Conducted by business stakeholders or a limited pilot group of users.

6. Deployment

  • Objective: Release the software to a production environment for end-users.
  • This is where the CI/CD pipeline (Part 2) automates and executes this stage.

7. Maintenance & Operations

  • Objective: Keep the system running smoothly, apply updates, and fix issues.
  • Key Activities for NBN:
    • Monitoring: Using tools (Prometheus, Grafana, ELK Stack) to track performance, errors, and usage.
    • Incident Response: Addressing outages or performance degradation urgently.
    • Patching: Applying security patches and updates.
    • Continuous Improvement: Gathering user feedback for future iterations and features.

Part 2: Industry-Standard CI/CD Pipeline Structure & Stages

This pipeline automates the integration, testing, and deployment of code changes for our three-tier microservices architecture.

Core Principles:

  • Everything as Code: Application code, infrastructure, and pipeline configuration are all in version control.
  • Automation: Every step that can be automated, is automated.
  • Fast Feedback: Developers get immediate feedback on their changes.

**Pipeline Stages (The "CD" can mean Continuous Delivery

This model means every change is automatically delivered to a production-like environment and is capable of being released, but a manual business approval is required to trigger the final deployment to live production. This gates risk and aligns technical readiness with business timing.

Here is the complete industry-standard CI/CD pipeline structure and stages, updated for Continuous Delivery with Manual Approval.

CI/CD Pipeline for NBN Project (Continuous Delivery Model)

The pipeline is divided into two primary parts: the fully automated Continuous Integration (CI) pipeline and the Continuous Delivery (CD) pipeline with a manual approval gate.

1. Continuous Integration (CI) Pipeline

Objective: To automatically validate every new code change merged into the main branch. This ensures the codebase is always in a stable, deployable state.

  • Trigger: A developer creates a Pull Request (PR) or merges code into the main branch (trunk/main).
  • Stages:
    1. Source Control & Branching:
      • Strategy: Trunk-Based Development is the industry standard for high-performing teams. Developers work on short-lived feature branches (from main) and merge via Pull Requests.
      • Tool: GitHub, GitLab, Bitbucket.

2.  Build & Compile:

    *   Action: The pipeline fetches the code and dependencies, compiles it (for languages like Java, C#), and creates a build artifact.

    *   Output: An immutable, versioned artifact (e.g., a Docker container image).

    *   Tool: Docker build, Maven, Gradle, .NET Core SDK.

    *   Key Practice: The version number (e.g., Docker tag) is unique and tied to the git commit hash.


    

  1. 

    Static Code Analysis (SAST):
    


      

    •   Action: Automated scanners analyze the source code for security vulnerabilities, bugs, and code smells without executing it.
      • 

    •   Tool: SonarQube, Snyk Code, Checkmarx.
      • 

    •   NBN Focus: Critical for enforcing security standards (ISM compliance) and code quality gates.
      • 

    

    2. 

  2. 

    Unit Testing:
    


      

    •   Action: Runs all unit tests in the codebase. This stage must pass for the pipeline to proceed.
      • 

    •   Tool: JUnit, pytest, Jest, NUnit.
      • 

    •   Key Metric: Code coverage percentage is often enforced as a quality gate (e.g., "must have >80% coverage").
      • 

    

    3. 

  3. 

    Package & Store Artifact:
    


      

    •   Action: The successfully built and tested Docker image is pushed to a container registry.
      • 

    •   Tool: Docker Hub, Amazon ECR, Azure Container Registry, Google Container Registry.
      • 

    •   Output: A production-ready artifact, stored and waiting for deployment.

      • 

    

    4.
Enter fullscreen mode Exit fullscreen mode

2. Continuous Delivery (CD) Pipeline

Objective: To automatically deploy the validated artifact through a series of progressively higher-fidelity environments, culminating in a manual approval for production release.

  • Trigger: The successful completion of the CI Pipeline, resulting in a new artifact in the registry.

Stage 1: Development / Test Environment Deployment

  • Environment: Ephemeral or long-running test environment. Cheap, easily destroyed and recreated.
  • Process: Fully automated.
  • Key Activities:
    • Deploy: The new container image is deployed to the Dev/K8s cluster.
    • Integration Testing: Automated tests verify communication between microservices and with downstream dependencies (e.g., test databases).
    • API Contract Testing: Tools like Pact or Postman ensure APIs haven't broken their contracts.

Stage 2: Staging / Pre-Production Environment Deployment

  • Environment: A near-perfect clone of production. Same configuration, similar infrastructure scale, with data masked for privacy.
  • Process: Often automated upon success in Dev, but can be manually triggered.
  • Key Activities:
    • Deploy: The exact same artifact that passed Dev is deployed here.
    • Performance & Load Testing: Tools like Apache JMeter or k6 simulate high traffic to ensure the system meets NBN's scalability and performance requirements.
    • Security Testing (DAST): Dynamic Application Security Testing scans the running application for vulnerabilities (e.g., OWASP ZAP).
    • User Acceptance Testing (UAT): Business stakeholders and QA testers validate that the application meets business requirements.
    • Compliance Checks: Automated checks for security baselines and configuration.

Stage 3: Production Deployment (The Manual Approval Gate)

  • Environment: The live production environment serving NBN customers and partners.
  • Process: Manually triggered after approval.
  • Key Activities:
    1. Hold State / Approval Gate: The pipeline automatically pauses. The artifact has been proven in Staging and is ready for production.
    2. Change Advisory Board (CAB) / Approval: A notification is sent to the designated approvers (e.g., Lead Engineer, Product Manager, Security Officer). They review:
      • Staging test results (performance, security).
      • Rollback plan.
      • Business context (e.g., is it a good time to release?).
    3. Manual Approval: An authorized person clicks "Approve" in the pipeline UI (e.g., Jenkins, GitLab).
    4. Deploy to Production: The pipeline resumes automatically and deploys the same, proven artifact to the production Kubernetes cluster using a controlled strategy (Blue-Green or Canary is mandatory for zero-downtime releases).
      • Blue-Green: Deploys to a duplicate production environment ("Green") and switches router traffic all at once.
      • Canary: Deploys to a small subset of users (e.g., 5%), monitors closely for errors, and gradually rolls out to 100% if metrics are good.
    5. Post-Deployment Verification: Automated health checks and real-user monitoring (e.g., Datadog, New Relic) confirm the release is successful.
    6. Automated Rollback (Crucial): If key metrics (error rate, latency) degrade beyond a threshold, the pipeline automatically triggers a rollback to the previous stable version.

This structure provides the NBN project with the agility of rapid, automated testing and staging, combined with the risk control of a human decision for the final production release. It ensures that what is approved for release is exactly what was tested, every time.

Top comments (0)