Git CI/CD

CI/CD stands for Continuous Integration and Continuous Deployment/Delivery .

It means your code is automatically tested and deployed every time you push.

This helps you catch bugs early and deliver features faster, with less manual work.

CI/CD automates the process of testing and deploying your code. This means:

• Find bugs before they reach users
• Deploy changes faster and more safely
• Reduce manual steps and mistakes
• Get quick feedback on every push

Every time you push code to your Git repository:

• The CI/CD service (like GitHub Actions or GitLab CI) detects the change
• It runs tests, builds your project, and can deploy automatically
• If something fails, you get notified right away

• GitHub Actions: Built into GitHub, uses YAML files in .github/workflows/
• GitLab CI/CD: Built into GitLab, uses .gitlab-ci.yml
• CircleCI: Works with GitHub/GitLab, easy setup for many languages
• Travis CI: Popular for open-source, uses .travis.yml
• Azure Pipelines: Works with Azure DevOps and GitHub, supports many platforms

A job is a group of steps that run together. Each job runs on a runner (a server).

Each step is a single task, like checking out code or running tests.

A runner is the computer/server that runs your jobs.

You can use the service's runners or set up your own for more control.

A trigger decides when your workflow runs.

Common triggers are push (every push) and pull_request (when a pull request is opened or updated).

Use environment variables for settings, and secrets for passwords or API keys.

Never hardcode secrets in your code!

CI/CD tools show logs for every job and step. Check logs to see what happened or to debug failures.

In GitHub Actions, click on a workflow run and see logs for each job/step.

You can skip CI/CD for a commit by adding [skip ci] to your commit message.

This is useful for documentation or minor changes.

Add a badge to your README to show CI/CD status.

This lets others see if your latest build passed.

• name: Sets the workflow's display name in GitHub.
• on: Decides when the workflow runs (here: every push).
• jobs: Groups together steps that run on a runner.
• build: The name of this job (can be anything).
• runs-on: Picks the type of server (here: Ubuntu Linux).
• steps: Each step does one thing, like checking out code or running tests.
• uses: Uses a pre-made GitHub Action (here: checks out your code).
• name: (under steps) Gives a step a label.
• run: Runs a shell command (here: npm test to run tests).

• If a build fails, check the logs for error messages.
• Make sure your secrets and environment variables are set correctly.
• You can rerun failed jobs from the CI/CD dashboard.
• Check the documentation for your CI/CD service for more help.
• Start small: automate tests first, then add deployment when ready.
• Keep secrets out of your code and never commit API keys.
• Use badges to show your build status in the README.