Designing a Unified Dev Platform for Traditional and Internet Business Models

Scenario Comparison

Two delivery models are contrasted:

Internet‑centric full‑stack DevOps – the development team performs all five stages (Code, Build, Test, Deploy, Monitor) in a single pipeline.

Traditional IT – development, implementation and operations are separated; an additional Assemble stage is required to package components into a solution bundle for the customer.

Both models share the DevOps goal of faster, more frequent and reliable build‑test‑release cycles.

1. Code Stage

The Code stage emphasizes rapid, low‑barrier development while collecting productivity metrics (e.g., lines of code, commit frequency). A contract‑based project layout is required so that engineering concerns (build scripts, static analysis, packaging) are handled by automated tooling, allowing developers to focus on core business logic.

In a microservice architecture each service is the smallest independently deployable unit. Required attributes include:

Clear, versioned API definitions (preferably YAML/JSON and visualised with Swagger/OpenAPI).

Independent compilation and packaging.

Contract‑driven directory structure that isolates source, resources, tests and build artefacts.

Typical directory layout (illustrated below) supports automated generation of API stubs and consistent metric collection.

Development workflow:

Define API contract in YAML/JSON.

Generate server/client stubs via Swagger.

Implement business logic in the generated skeleton.

Commit code to a Git repository (GitHub or GitLab).

Supporting services such as a microservice‑initialisation manager (CodeInit) can automatically create the contract‑based project skeleton and record key indicators (language, owner, commit count, etc.).

2. Build Stage

The Build stage validates source quality and produces executable artefacts. A typical pipeline consists of the following steps:

Checkout : Pull source from the Git repository to the build agent.

Gate checks : Enforce contract‑based directory rules, compute cyclomatic complexity, run static analysis (e.g., FindBugs, SpotBugs), and perform style checks.

Compile & package : Use the language‑specific compiler (e.g., javac, mvn package, go build) to produce binaries and bundle configuration files.

Push artefacts : Upload the resulting package to an artefact repository – FTP server, Nexus/Artifactory, or Docker image registry.

Metrics collection : Record build count, success/failure ratio, duration, and code‑quality scores for downstream reporting.

3. Assemble Stage

The Assemble stage automatically composes microservice packages into higher‑level artefacts:

Service bundle : A collection of related microservices that together provide a business capability.

Solution bundle : One or more service bundles packaged as a deployable solution (ZIP, container image, etc.).

Assembly rules are defined contractually – each rule specifies the target bundle type and the constituent packages. The pipeline therefore produces a ready‑to‑deploy solution without manual composition.

4. Deploy Stage

Deploy belongs to the Ops side and automates placement of artefacts onto target nodes. Core concepts:

Package : Deliverable artefact (ZIP, Docker image, etc.).

Environment : Logical stages – Alpha (self‑validation), Beta (integration), Gamma (pre‑production), Production.

Node : Physical or virtual machine where the package is installed; provisioning may be handled by a separate CMDB, cloud‑management platform, or bare‑metal installer.

The deployment system visualises and orchestrates these actions, often delegating container orchestration to Kubernetes.

5. Monitor Stage

Monitoring, also part of Ops, collects metrics from hardware, OS and application layers, provides call‑chain tracing, alerting and fault diagnosis. In addition to runtime health, the monitor records the health of the Dev pipeline itself (Code, Build, Assemble metrics).

Technical Tool Survey

Docker

Used in Build/Assemble to create immutable container images. Supports both stateless and stateful workloads (e.g., side‑car containers, data‑volume containers).

Kubernetes

Orchestrates Deploy stage – handles rollout, scaling, self‑healing and service discovery for containerised solutions.

Jenkins

Provides the CI/CD pipeline that stitches Code → Build → Assemble. Extensible via plugins (e.g., Docker, Kubernetes, static‑analysis tools) and supports custom Groovy scripts for complex workflows.

Gerrit

Enforces code‑review policies in the Code stage, offering role‑based access control and seamless integration with Git repositories.

GitHub / GitLab

Serve as the source‑code repository. Both expose REST APIs for automation; the choice depends on organisational preferences for self‑hosting (GitLab) versus SaaS (GitHub).

The combination of a contract‑driven project structure and integrated tooling enables teams to develop microservices rapidly, automatically assemble them into solution packages, and deploy those packages reliably across multiple environments.