Weaveworks 2022.03 release featuring Magalix PaC | Learn more
Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
In this Lab we will go through how to create CI/CD pipeline using circleci in the following steps:
If you sign in to CircleCI using a Github account, it will ask for permission to read your creations. You can also go to CircleCI and list all your projects, if you give permission to do so. Click the "plan setup" button and proceed.
CircleCI needs us to create the configuration file at this path: PROJECT_ROOT/.circleci/config.yml. Ensure you create that file at the root of your project.
If you want to test the CircleCI configuration in local, you can use the following commands:
Each and every box in the sample pipeline diagram above is a task. It executes the actual collection of steps provided inside a system. The machine that executes each step is called an executor. There are several executors (Docker, Shell, VM), but we'll use the Docker Executor to build an example of "Hello World."
version: 2
jobs:
build:
docker:
- image: busybox:latest
steps:
- run:
name: Hello World
command: echo "Hello World"
However, this example is not quite sufficient to build a complete pipeline. To create multiple jobs and link them together, we’ll need to create workflows:
version: 2
jobs:
unit_test:
docker:
- image: busybox:latest
steps:
- run:
name: Unit Test
command: echo "Going to run Unit Test"
linting:
docker:
- image: busybox:latest
steps:
- run:
name: Lint Test
command: echo "Going to run Lint Test"
workflows:
version: 2
sample_pipeline:
jobs:
- unit_test
- linting
We’ve created the workflow named sample_pipeline and assigned it two jobs:
Here we’ll create multiple jobs with dependencies between them:
version: 2
jobs:
unit_test:
docker:
- image: busybox:latest
steps:
- run:
name: Unit Test
command: echo "Going to run Unit Test"
linting:
docker:
- image: busybox:latest
steps:
- run:
name: Lint Test
command: echo "Going to run Lint Test"
build_artifact:
docker:
- image: busybox:latest
steps:
- run:
name: Build Artifact
command: echo "Going to run the build artifact"
deploy_to_dev:
docker:
- image: busybox:latest
steps:
- run:
name: Deploy to Dev
command: echo "Going to deploy to dev"
deploy_to_qa:
docker:
- image: busybox:latest
steps:
- run:
name: Deploy to QA
command: echo "Going to deploy to QA"
- run:
name: Step no 2
command: echo "Going to deploy to QA again"
workflows:
version: 2
sample_pipeline:
jobs:
- linting
- unit_test
- build_artifact:
requires:
- unit_test
- linting
- deploy_to_dev:
requires:
- build_artifact
- deploy_to_qa:
requires:
- deploy_to_dev
Now, the only part that’s missing is the approval process - if we don't have it, then the whole pipeline will run for each and every check-in (and we don’t want that to happen):
workflows:
version: 2
sample_pipeline:
jobs:
- linting
- unit_test
- build_artifact:
requires:
- unit_test
- linting
- deploy_to_dev:
requires:
- build_artifact
- hold_for_approval:
type: approval
requires:
- deploy_to_dev
- deploy_to_qa:
requires:
- hold_for_approval
For readability, we’ve pasted only the workflows and left out the jobs part. Again, you can check the entire configuration here. Some points to pay close attention to:
Self-service developer platform is all about creating a frictionless development process, boosting developer velocity, and increasing developer autonomy. Learn more about self-service platforms and why it’s important.
Explore how you can get started with GitOps using Weave GitOps products: Weave GitOps Core and Weave GitOps Enterprise. Read more.
More and more businesses are adopting GitOps. Learn about the 5 reasons why GitOps is important for businesses.
Implement the proper governance and operational excellence in your Kubernetes clusters.
Comments and Responses