My cheat on ci/cd pipeline

Pipelines are the top-level component of continuous integration, delivery, and deployment. Pipelines (in Gitlab? or in general?) comprise:

• Jobs, which define what to do. For example, jobs that compile or test code.
• Stages, which define when to run the jobs. For example, stages that run tests after stages that compile the code.

Jobs are executed by runners.

Multiple jobs in the same stage are executed in parallel, if there are enough concurrent runners.

• If all jobs in a stage succeed, the pipeline moves on to the next stage.
• If any job in a stage fails, the next stage is not (usually) executed and the pipeline ends early.
• In general, pipelines are executed automatically requiring no intervention once created. However, there are also times when you can manually interact with a pipeline.
• A typical pipeline might consist of four stages, executed in the following order:
  • A build stage, with a job called compile. (cisco calls it "change stage"
  • A test stage, with two jobs called test1 and test2.
  • A staging stage, with a job called deploy-to-stage.
  • A production stage, with a job called deploy-to-prod.
  • That's it.

From cisco learning on CI-CD pipelines This is a common-pipeline:

You commit a change for example.yml to a code repository.
The repository executes syntax and sanity checks, code review rules, and:

- Accepts your commit and notifies the CI/CD server to run tests.
- Rejects your commit based on failed checks.

CI/CD prepares an environment and runs predefined tests for any Ansible playbook:

- pip install ansible==2.8.1
- ansible-version
- ansible-playbook example.yml --syntax-check
- ansible-playbook -i staging_inventory.cfg -check
- ansible-playbook -i staging_inventory.cfg -vvvv

You are notified that you can propagate your changes to the production environment.

Consists of:

• source code repository
• build stage (source code, dependencies, and static code analytics)
• test stage (unit and integration tests. ([end-to-end tests])
• deploy stage (packaging, staging, and production)

The pipeline can be triggered automatically with a commit, or manually by a DevOps engineer.

A runnable instance is built during the build stage from the source code and the needed dependencies

Followed by:

From:

Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project.

• Jobs are the basic configuration component.
• Stages are defined by using the stages keyword.

For a list of configuration options in the CI pipeline file, see the GitLab CI/CD Pipeline Configuration Reference.

You can also configure specific aspects of your pipelines through the GitLab UI. For example:

• Pipeline settings for each project.
• Pipeline schedules.
• Custom CI/CD variables.

There are a lot of tools that can help you implement a CI/CD pipeline. Tools based on Git (GitLab, GitHub, and Bitbucket) all provide you with a code repository as well as with the CI/CD pipeline, while tools like Jenkins or CircleCI do not provide software repositories. Tools such as Jenkins, CircleCI, rely on code repositories, hosted somewhere else, to trigger the pipeline with the help of /APIs.

• Plan Scrum + Agile for frequent microincremental changes
• Code Using and IDE
• Build rapidly and incrementally mergee code commits
• Test automated verification of enhancements, often with test-driven deployment practices. Often with pytest, unittest or other test frameworks
• Release repository commits and documrentation
• Deploy Update the code base
• Operate in production, with monitoring and orchestartion
• Monitor & Optimize data collection, analysis, feedback with machine learning that closes the loop back to plan.