Last active
March 3, 2026 21:24
-
-
Save 13013SwagR/97206f1236c99a59e73df2e228e430d6 to your computer and use it in GitHub Desktop.
CI-CD Standard 0.0.1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Tasks definition | |
| # Tasks represent code or programs to be executed with the required parameters | |
| # Usage rules: | |
| # 1. Variables MUST NOT be made of other variables. This should be handled within the service integration | |
| # Implementation rules: | |
| # 1. Tasks MUST call at least one service | |
| # 2. Tasks MUST produce a result | |
| # 3. Tasks result object has 3 sub-objects: | |
| # the result code(integer), the execution log artifact (URL), the pipeline artifacts (URL) | |
| product_data: | |
| name: # Name of the product | |
| tasks: | |
| # Example build type task | |
| - name: build_app_a # The task name, MUST be unique | |
| type: build # The task type | |
| after: [] # The tasks required to be done and successful before this one | |
| build: | |
| environment: my-docker-image # The environment in which to build the product | |
| command: docker build $REPOSITORY_DIR # The command to be executed to build the product | |
| # If multiple commands are required, then it should be a script | |
| # Implementation rules: | |
| # 1. The build MUST produce one or many build artifacts | |
| # 2. Only a build CAN produce a build artifact | |
| # 3. The build artifacts MUST have a unique build identifier per artifact, known as the build number | |
| # Example release type task | |
| - name: alpha_release_app_a | |
| type: release # The task type | |
| after: ['build_app_a'] # The tasks required to be done and successful before this one | |
| release: | |
| level: alpha # The release level of this task, possible values based on **semantic versioning | |
| type: MINOR # The impact of this release, possible values based on **semantic versioning | |
| metadata: # [Optional] | |
| # Implementation rules: | |
| # 1. A Release task MUST create a release or pre-release version that will be associated | |
| # with the corresponding build number | |
| # 2. A Release task MUST NOT produce new build artifacts. It MAY tag upstream build artifacts | |
| # 3. Versioning SHOULD implement **semantic versioning 2.0.0 standard | |
| - name: deploy_app_a_to_prod | |
| type: deployment | |
| after: ['alpha_release_app_a'] | |
| deployment: | |
| environment: staging # [Required] the target environment | |
| release: | |
| task: alpha_release_app_a # [Required] Reference a previous release task | |
| # Implementation rules: | |
| # 1. The deployment task MUST only update a desired state database (example: git repository) | |
| # for the target environment. It MAY trigger a synchronization of the orchestrator with the database | |
| # 2. Build artifacts MUST be pulled by the orchestrator | |
| # 3. Deployment configurations SHOULD be stored and versioned within the deployed application's repository | |
| ## Note: In this context, an orchestrator is a service able to read the desired state database | |
| ## and apply/deploy the desired state, example: ***ArgoCD. More on this topic in future article |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment