CI involves developers merging their changes into a shared repository several times a day. Each merge is then automatically built and tested to catch bugs early in the development cycle.

Key Features:

1. Frequent code check-ins
2. Automated building and testing
3. Quick detection of integration issues

CD is an extension of Continuous Integration. It ensures that the codebase is always in a deployable state. This practice allows you to manually trigger deployments to production (or other environments), but everything up to that point is automated.

Key Features:

1. Codebase is always deployable
2. Manual approval is required for deployment to production
3. Includes automated testing and staging

This is an advanced stage of CD. Here, every change that passes the automated testing phase is automatically deployed to the production environment without manual intervention.

Key Features:

1. Fully automated pipeline, including production deployment
2. No manual intervention for deployments
3. Quick release of new features and fixes

A CI/CD pipeline is an automated process utilized by software development teams to streamline the creation, testing and deployment of applications. “CI” represents continuous integration, where developers frequently merge code changes into a central repository, allowing early detection of issues.

from docs GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline. you should install GitLab Runner on a machine that's separate from the one that hosts the GitLab instance for security and performance reasons.

A GitLab Runner is an executer used to run CI/CD jobs and send the results back to GitLab. Runners are the workhorses of GitLab CI/CD pipelines, performing tasks such as building, testing, and deploying code. They are flexible and can run jobs in different environments, such as Docker, shell, and Kubernetes.

GitLab Runners provide the following benefits:

1. Scalability: Easily scale the number of runners to handle multiple jobs concurrently.
2. Flexibility: Configure runners to use different execution environments tailored to specific job requirements.
3. Isolation: Run jobs in isolated environments to ensure consistency and prevent conflicts.

The GitLab architecture begins by choosing the instance type, whether it’s self-managed or hosted on gitlab.com. Following this, you’ll proceed to register the runners, which are available in three categories: shared runners, specific runners, and group runners. These runners play a crucial role in fetching jobs from the instance and routing them to executors. These executors, residing on the same server or instance as the runner, can be configured to utilize various methods such as Docker or shell scripts to execute tasks. After completing the job, the executor transmits the results back to the runner, which then relays them to either the GitLab instance or the self-managed environment. Tags are employed within scripts to precisely define which runners should be utilized for specific tasks.

Shared Runners are available to all projects within a GitLab instance. They are managed by the GitLab administrator and are ideal for general-purpose tasks and smaller projects. Shared runners are convenient as they do not require individual setup for each project.

Dedicated Runners (or specific runners) are assigned to specific projects or groups. They provide greater control and customization for the project’s requirements. Dedicated runners are particularly useful for:

Projects with specific build environments. Handling sensitive or resource-intensive tasks. Ensuring dedicated resources are available for critical pipelines.