Core Concepts
This article introduces the core concepts of Zadig to help users establish a basic understanding of the platform.
# Project
A Zadig project is a complete business unit, product, or system that includes workflows, environments, services, builds, tests, code review, versions, and other resources. Users can perform service development, deployment, integration testing, and version release within a project to achieve continuous delivery.
Zadig supports five project types:
- K8s YAML project: Uses Kubernetes as the infrastructure and manages services with Kubernetes YAML
- K8s Helm Chart project: Uses Kubernetes as the infrastructure and manages services with Helm Charts
- K8s managed project: Hosts existing cluster resources so you can view logs, debug in Pods, and update images in Zadig
- Freestyle project: Targets hosts and client releases such as Android, iOS, Windows, and mini programs
- Agent project: Registers and manages external agents for AI tasks in workflows
# Workflow
A typical software development process includes: Write code → Build → Deploy → Test → Release.
A Zadig workflow orchestrates this delivery process. It consists of stages and tasks: stages run sequentially; a stage can contain multiple tasks, which may run sequentially or in parallel. Workflows can be configured in the UI or YAML, and can also be created from templates.
Workflows can orchestrate builds, deployments, code review, tests, manual approvals, canary releases, configuration and data changes, and AI tasks. They can be triggered by Git events, schedules, or project management systems.
# Environment
A Zadig environment is a collection of services, their configurations, and the runtime. Kubernetes-based environments map one-to-one with a Kubernetes Namespace. Multiple environments can be created from the same service configuration.
By infrastructure, environments are classified as K8s YAML, K8s Helm Chart, K8s managed, and host environments. By scenario, they are classified as test and production environments. Environments support self-test mode, sleep and wake, and AI environment inspection to identify runtime risks.
# Service
A Zadig service is a deployable unit that provides capabilities after it is running. It can be a set of Kubernetes resources (Ingress, Service, Deployment/StatefulSet/DaemonSet/CronJob, ConfigMap, and so on), a complete Helm Chart, or a host service.
By infrastructure, services correspond to K8s YAML, Helm Chart, managed, and host services. By scenario, they are classified as test services and production services, used in test and production environments respectively.
# Service Components
Service components are the smallest independently updatable units in a container service (typically corresponding to an image). A service may contain multiple service components. Workflow builds and deployments operate at the service-component level.
# Build
A Zadig build defines how code is turned into deliverables. It supports pulling code, compiling, building images or packages, pushing images, uploading to object storage, and using build caches. Builds can run on Kubernetes or hosts.
A service can have multiple builds, selected as needed in a workflow. A single build can also be shared by multiple services.
# Test
Zadig tests manage automated test configuration and execution, covering unit, integration, API, UI, performance, and end-to-end scenarios. Tests can run independently or from a workflow, and can be shared across projects.
# Code Review
Zadig code review is a project resource. It supports AI review, Sonar scanning, and custom scanning. It can run independently or be orchestrated in workflows, with quality gates, multi-repository scans, and automatic triggers on code changes.
# Version Management
A Zadig version is a complete deliverable captured from an environment. K8s YAML projects deliver images and service configurations; Helm Chart projects deliver Charts and images. Versions can be deployed to a specified environment through a workflow, or used to recreate an environment.
# Release Plan
A release plan is used to plan, approve, and execute a release. It can associate requirements and workflows, set a release window and owner, support Zadig, Feishu, and DingTalk approvals, and keep a full operation log.
