Modern development teams regularly add features, fix bugs, and release new versions of their applications. However, manually testing, building, and deploying every code change takes time. It may also cause errors when developers perform the same steps differently.

GitLab CI/CD solves this problem through automation.

With GitLab CI/CD, developers can automatically check their code, run tests, create builds, and deploy applications. The complete process begins when someone pushes code or creates a merge request.

This beginner’s guide explains what GitLab CI/CD is, how it works, how to create a .gitlab-ci.yml file, and how to build your first pipeline.

---

What Is GitLab?

GitLab is a DevSecOps platform that helps teams plan, develop, test, secure, and deliver software.

Developers commonly use GitLab to:

• Store Git repositories
• Track source-code changes
• Create and review merge requests
• Manage project issues
• Run automated tests
• Build applications
• scan code for security problems
• Manage software releases
• Deploy applications
• Monitor development workflows

Instead of using a separate platform for every task, a team can manage much of the software-development lifecycle inside GitLab.

GitLab offers different deployment options:

• GitLab.com: GitLab hosts and manages the platform.
• GitLab Self-Managed: An organization installs GitLab on its own infrastructure.
• GitLab Dedicated: GitLab provides a dedicated hosted environment for an organization.

Beginners usually start with GitLab.com because it requires less configuration.

---

What Is GitLab CI/CD?

GitLab CI/CD is GitLab’s built-in system for automating software integration, testing, building, and deployment.

CI/CD stands for:

• CI: Continuous Integration
• CD: Continuous Delivery or Continuous Deployment

Continuous Integration checks new code changes frequently. Meanwhile, Continuous Delivery prepares those changes for release. Continuous Deployment goes further by releasing successful changes automatically.

GitLab connects these processes through pipelines.

According to the official GitLab CI/CD documentation, developers define a pipeline by adding a .gitlab-ci.yml file to their project. This file describes the stages, jobs, scripts, dependencies, variables, and execution conditions.

---

What Is a GitLab CI/CD Pipeline?

A GitLab CI/CD pipeline is a collection of automated jobs that GitLab runs for a project.

A pipeline may perform tasks such as:

1. Download the latest source code
2. Install project dependencies
3. Check code formatting
4. Analyze source code
5. Run automated tests
6. Create a production build
7. Store build artifacts
8. Deploy the application
9. Run security scans
10. Send deployment results

For example, suppose a Flutter developer pushes code to a GitLab repository. GitLab can automatically run flutter analyze, execute tests, and create an Android APK.

If every job succeeds, the pipeline passes. However, if a required job fails, GitLab marks the pipeline as failed and stops dependent work.

---

Why Should Developers Use GitLab CI/CD?

GitLab CI/CD helps development teams improve speed, reliability, and consistency.

Automated Testing

The pipeline can run tests whenever developers push code. As a result, the team discovers many problems before merging or deploying the changes.

Faster Releases

Automation reduces repetitive manual work. Therefore, developers can release updates more frequently.

Consistent Builds

GitLab runners follow the same instructions each time. Consequently, build results do not depend entirely on an individual developer’s computer.

Early Error Detection

Code analysis and automated testing reveal errors during development. Fixing an early problem usually costs less than fixing it after release.

Better Collaboration

GitLab displays pipeline results on commits and merge requests. Reviewers can therefore check whether the code passed all required tests before approving it.

Safer Deployments

Teams can add staging environments, manual approval jobs, protected variables, and deployment rules. These controls help prevent unauthorized or unstable production releases.

Complete Visibility

GitLab stores pipeline histories, job logs, test reports, artifacts, and deployment details. Therefore, team members can understand what happened during a release.

---

Important GitLab CI/CD Concepts

Before creating a pipeline, beginners should understand its main parts.

Pipeline

A pipeline represents the complete automated workflow for a specific code version.

GitLab can create a pipeline after:

• A code push
• A merge request
• A Git tag
• A scheduled event
• A manual action
• An API trigger
• Another pipeline

Every pipeline contains one or more jobs.

Job

A job is an individual unit of work.

For example, a pipeline may contain these jobs:

• check-format
• run-tests
• build-application
• deploy-staging
• deploy-production

Each job contains commands that a GitLab runner executes.

Stage

A stage groups jobs that belong to the same part of the workflow.

Common stages include:

stages:
  - analyze
  - test
  - build
  - deploy

By default, GitLab runs stages in the listed order. Jobs inside the same stage can run in parallel when suitable runners remain available.

Runner

A GitLab runner is an application that executes pipeline jobs.

The runner receives a job from GitLab, prepares an execution environment, downloads the project, runs the commands, and sends the result back to GitLab.

A runner may use:

• A physical computer
• A virtual machine
• A Docker container
• A Kubernetes cluster
• A cloud-hosted machine

GitLab.com provides hosted runners for supported environments. Alternatively, teams can register their own runners. The GitLab runner documentation explains the available runner types and configuration options.

Script

The script keyword contains the shell commands that a runner must execute.

For example:

test-job:
  script:
    - npm install
    - npm test

Here, the runner installs dependencies and runs the project’s tests.

Artifact

An artifact is a file or directory produced by a job.

Common artifacts include:

• APK or AAB files
• Test reports
• Code coverage reports
• Compiled web applications
• ZIP archives
• Log files
• Docker-related output
• Documentation

GitLab can store artifacts after a job finishes. Another job or an authorized user can then download them.

Cache

A cache stores reusable files between pipeline runs.

For example, a project can cache downloaded dependencies. The next pipeline may use those stored files instead of downloading everything again.

Although artifacts and caches may look similar, they serve different purposes:

Feature	Cache	Artifact
Main purpose	Speed up jobs	Store job output
Common content	Dependencies	Builds and reports
Reliability	May not always be available	Stored as pipeline output
Used by	Future jobs or pipelines	Users and later jobs
Example	.pub-cache or node_modules	APK or test report

Variable

A CI/CD variable is a key-value pair available inside pipeline jobs.

Variables can store:

• Environment names
• API URLs
• Build modes
• Version values
• Deployment settings
• Tokens and credentials

GitLab also creates predefined variables such as:

• $CI_COMMIT_BRANCH
• $CI_COMMIT_SHA
• $CI_PROJECT_DIR
• $CI_PIPELINE_ID
• $CI_JOB_ID

Environment

An environment represents a deployment target.

Common environment names include:

• Development
• Testing
• Staging
• Production

GitLab can record which code version each environment uses.

---

What Is the .gitlab-ci.yml File?

The .gitlab-ci.yml file is the main configuration file for a GitLab CI/CD pipeline.

Developers normally place this file in the root directory of the GitLab repository.

Example project structure:

my-project/
├── src/
├── tests/
├── package.json
├── README.md
└── .gitlab-ci.yml

The filename begins with a dot. Therefore, some operating systems and file browsers may treat it as a hidden file.

GitLab reads this YAML file and creates the pipeline from its configuration.

A .gitlab-ci.yml file may define:

• Pipeline stages
• Jobs
• Commands
• Docker images
• Services
• Variables
• Caching rules
• Artifacts
• Job conditions
• Dependencies
• Deployment environments
• Manual approval steps

YAML uses indentation to represent structure. Therefore, correct spacing matters.

Use spaces instead of tabs. In addition, keep the indentation consistent throughout the file.

---

Your First GitLab CI/CD Pipeline

The following example creates a simple pipeline with build, test, and deploy stages:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Building the application..."
    - mkdir build
    - echo "Application build completed" > build/result.txt
  artifacts:
    paths:
      - build/

test-job:
  stage: test
  script:
    - echo "Running automated tests..."
    - test -f build/result.txt

deploy-job:
  stage: deploy
  script:
    - echo "Deploying the application..."
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Let us understand each section.

---

Understanding the stages Section

The stages keyword defines the pipeline’s main phases and their order:

stages:
  - build
  - test
  - deploy

GitLab starts the build stage first. If the required build jobs pass, it moves to the test stage. Finally, successful tests allow the deploy stage to begin.

If an important job fails, later stages usually do not run.

---

Understanding a Job

This configuration creates a job named build-job:

build-job:
  stage: build
  script:
    - echo "Building the application..."

The job belongs to the build stage. Its script prints a message in the job log.

Job names can describe their purpose. For example:

flutter-analyze:
node-unit-tests:
build-android-app:
deploy-production:

Clear names make pipeline results easier to understand.

---

Understanding artifacts

The build job creates and stores a directory:

artifacts:
  paths:
    - build/

After the job finishes, GitLab uploads the build directory as an artifact.

You can also define an expiration time:

artifacts:
  paths:
    - build/
  expire_in: 7 days

This setting helps control artifact storage.

For more details, see the official GitLab job artifacts guide.

---

Understanding rules

The deployment job includes this condition:

rules:
  - if: '$CI_COMMIT_BRANCH == "main"'

Therefore, GitLab adds the deployment job only when the pipeline runs for the main branch.

The rules keyword allows a team to control when jobs appear or run.

---

How to Create a GitLab CI/CD Pipeline Step by Step

Follow these steps to create your first pipeline.

Step 1: Create a GitLab Project

Open GitLab and create a new blank project.

Choose:

• Project name
• Project slug
• Visibility level
• README option

You can create a private project while learning.

Step 2: Add Your Source Code

Clone the repository to your computer:

git clone https://gitlab.com/your-username/your-project.git

Next, open the project directory:

cd your-project

Add your application files to the repository.

Step 3: Create .gitlab-ci.yml

Create a file named:

.gitlab-ci.yml

Add this basic configuration:

stages:
  - test

first-test:
  stage: test
  script:
    - echo "My first GitLab pipeline is running"
    - echo "Pipeline completed successfully"

Step 4: Commit the Pipeline File

Run the following commands:

git add .gitlab-ci.yml
git commit -m "Add first GitLab CI pipeline"
git push origin main

The push triggers a new pipeline.

Step 5: Open the Pipeline

Inside the GitLab project:

1. Open Build
2. Select Pipelines
3. Open the latest pipeline
4. Select the job
5. Read the job log

A green status means the pipeline passed. In contrast, a red status means at least one required job failed.

---

How Does GitLab Run a Pipeline?

When you push the .gitlab-ci.yml file, GitLab follows a defined process.

1. GitLab detects the repository event.
2. It reads and validates the YAML configuration.
3. The platform creates a pipeline.
4. GitLab adds eligible jobs based on their rules.
5. Available runners request jobs.
6. A runner receives a matching job.
7. The runner prepares the environment.
8. It downloads the source code.
9. The runner executes the job script.
10. GitLab receives logs, status information, and artifacts.
11. Successful stages allow later stages to begin.
12. The final pipeline receives a passed, failed, canceled, skipped, or blocked status.

This process happens automatically after the configured trigger.

---

GitLab Runner Explained

GitLab does not directly execute the commands inside every job. Instead, runners perform the actual work.

A runner:

• Receives jobs from GitLab
• Creates an execution environment
• Checks out the requested code
• Restores available caches
• Downloads required artifacts
• Executes commands
• Uploads new artifacts
• Reports the job result

GitLab-Hosted Runners

GitLab.com provides hosted runners that can execute jobs without requiring users to maintain their own infrastructure.

Hosted runners offer a simple starting point. However, usage limits and available features can depend on the GitLab plan.

Self-Managed Runners

A self-managed runner operates on a machine controlled by the user or organization.

Teams may choose one when they need:

• Custom hardware
• Private network access
• Specialized software
• Greater environment control
• A specific operating system
• Internal deployment access
• Dedicated build capacity

Self-managed runners require installation, updates, security controls, and regular maintenance.

Runner Tags

Tags connect jobs with suitable runners.

For example:

android-build:
  stage: build
  tags:
    - android
    - flutter
  script:
    - flutter build apk

A runner must have matching tags before it can accept this job.

If no suitable runner exists, the job may remain pending.

---

Using Docker Images in GitLab CI/CD

A Docker image provides a prepared environment for a job.

For example, a Node.js project can use:

image: node:22

test-job:
  script:
    - npm ci
    - npm test

The runner starts a container from the selected Node.js image. It then downloads the project and runs the commands inside that container.

You can apply one image to all jobs:

default:
  image: node:22

Alternatively, each job can use a different image:

test-node-20:
  image: node:20
  script:
    - npm ci
    - npm test

test-node-22:
  image: node:22
  script:
    - npm ci
    - npm test

Pinning an appropriate image version improves build consistency.

---

GitLab CI/CD Example for a Node.js Project

The following pipeline installs dependencies, checks code, runs tests, and creates a build:

image: node:22

stages:
  - quality
  - test
  - build

cache:
  key:
    files:
      - package-lock.json
  paths:
    - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

lint:
  stage: quality
  script:
    - npm run lint

unit-tests:
  stage: test
  script:
    - npm test
  artifacts:
    when: always
    reports:
      junit: junit.xml

production-build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 7 days

This pipeline uses Node.js as its environment. It also caches downloaded packages, runs linting, executes tests, and saves the production build.

---

GitLab CI/CD Example for Flutter

Flutter developers can also use GitLab CI/CD for code analysis, testing, and Android builds.

image: ghcr.io/cirruslabs/flutter:stable

stages:
  - quality
  - test
  - build

variables:
  PUB_CACHE: "$CI_PROJECT_DIR/.pub-cache"

cache:
  key:
    files:
      - pubspec.lock
  paths:
    - .pub-cache/

before_script:
  - flutter --version
  - flutter pub get

format-check:
  stage: quality
  script:
    - dart format --output=none --set-exit-if-changed .

analyze:
  stage: quality
  script:
    - flutter analyze

unit-tests:
  stage: test
  script:
    - flutter test

build-apk:
  stage: build
  script:
    - flutter build apk --release
  artifacts:
    paths:
      - build/app/outputs/flutter-apk/app-release.apk
    expire_in: 7 days
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

This pipeline performs four main tasks:

1. Checks Dart formatting
2. Analyzes the Flutter code
3. Runs Flutter tests
4. Creates a release APK on the main branch

A production mobile pipeline needs additional configuration for signing, secret files, versioning, and store deployment.

Building an iOS application also requires a macOS runner with Xcode and valid Apple signing credentials.

---

Using before_script and after_script

The before_script section runs commands before a job’s main script.

Example:

test-job:
  before_script:
    - npm ci
  script:
    - npm test

Meanwhile, after_script runs cleanup or reporting commands after the main script:

test-job:
  script:
    - npm test
  after_script:
    - echo "Test job finished"

You can use the default section to share common configuration:

default:
  before_script:
    - echo "Preparing job environment"
  retry: 1

Jobs inherit these values unless they provide their own configuration.

---

Using CI/CD Variables

Variables make pipeline files more flexible.

You can define a non-sensitive variable inside .gitlab-ci.yml:

variables:
  APP_ENV: "testing"

test-job:
  script:
    - echo "Current environment is $APP_ENV"

However, sensitive values should not appear directly in the repository.

Add private variables from the project’s CI/CD settings instead.

Common secret variables include:

• API_TOKEN
• SERVER_PASSWORD
• SSH_PRIVATE_KEY
• ANDROID_KEYSTORE_PASSWORD
• PLAY_STORE_SERVICE_ACCOUNT
• FIREBASE_TOKEN
• AWS_ACCESS_KEY_ID

GitLab supports security controls for variables:

• Masked variables hide supported values from job logs.
• Protected variables limit values to protected branches or tags.
• Environment scopes restrict values to selected environments.

Never print secret variables with commands such as echo.

---

Using rules to Control Jobs

The rules keyword decides whether GitLab adds a job to a pipeline and how it behaves.

Run a Job on the Main Branch

deploy-production:
  script:
    - ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Run a Job for Merge Requests

merge-request-tests:
  script:
    - npm test
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Run a Job for Git Tags

create-release:
  script:
    - ./create-release.sh
  rules:
    - if: '$CI_COMMIT_TAG'

Create a Manual Job

deploy-production:
  script:
    - ./deploy-production.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

In this example, the deployment does not begin automatically. An authorized user must start it.

---

Creating Deployment Environments

The environment keyword tells GitLab where a job deploys the application.

deploy-staging:
  stage: deploy
  script:
    - ./deploy-staging.sh
  environment:
    name: staging
    url: https://staging.example.com

For production:

deploy-production:
  stage: deploy
  script:
    - ./deploy-production.sh
  environment:
    name: production
    url: https://example.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

GitLab can then display the deployment history and current environment information.

Production environments should use strict access controls.

---

How to Use Artifacts

Artifacts allow a job to save important output.

Example:

build-website:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    name: "website-$CI_COMMIT_SHORT_SHA"
    paths:
      - dist/
    expire_in: 14 days

The artifact name includes the short commit SHA. Therefore, each stored build remains easier to identify.

You can save artifacts even when a job fails:

artifacts:
  when: always
  paths:
    - logs/

This approach is useful for error logs and test reports.

---

How to Use Cache Correctly

Caching can make pipelines faster.

A Node.js example may look like this:

cache:
  key:
    files:
      - package-lock.json
  paths:
    - .npm/

A Flutter project may cache packages:

variables:
  PUB_CACHE: "$CI_PROJECT_DIR/.pub-cache"

cache:
  key:
    files:
      - pubspec.lock
  paths:
    - .pub-cache/

A cache key based on the dependency lock file changes when dependencies change. Consequently, GitLab can avoid using an outdated cache.

Do not treat a cache as permanent file storage. Store essential builds and reports as artifacts instead.

---

Running Jobs in Parallel

Jobs in the same stage can run in parallel.

stages:
  - test

unit-tests:
  stage: test
  script:
    - npm run test:unit

integration-tests:
  stage: test
  script:
    - npm run test:integration

security-check:
  stage: test
  script:
    - npm audit

If multiple runners remain available, all three jobs can start around the same time.

Parallel execution may reduce the total pipeline duration.

---

Using needs for Faster Pipelines

Traditional pipelines wait for every job in one stage before starting the next stage.

The needs keyword allows a job to start as soon as its required jobs finish.

stages:
  - build
  - test
  - deploy

build-app:
  stage: build
  script:
    - ./build.sh

build-docs:
  stage: build
  script:
    - ./build-docs.sh

test-app:
  stage: test
  needs:
    - build-app
  script:
    - ./test.sh

Here, test-app only needs build-app. Therefore, it does not need to wait for an unrelated documentation build.

This structure creates a directed acyclic graph, often called a DAG pipeline.

---

Manual Jobs and Approvals

Some actions should require a human decision.

For example, a team may want automatic testing but manual production deployment.

deploy-production:
  stage: deploy
  script:
    - ./deploy-production.sh
  environment:
    name: production
  when: manual
  allow_failure: false

The pipeline waits until an authorized person starts the job.

Manual control works well for:

• Production releases
• Database migrations
• Store submissions
• Destructive maintenance tasks
• Emergency rollback operations

For stronger controls, teams can also protect environments and branches.

---

GitLab CI/CD Pipeline Types

GitLab supports several pipeline structures.

Branch Pipeline

A branch pipeline runs after code changes on a branch.

Merge Request Pipeline

A merge request pipeline checks proposed changes before the team merges them.

Tag Pipeline

A tag pipeline usually creates a versioned build or software release.

Scheduled Pipeline

A scheduled pipeline runs at a selected time.

Teams may use schedules for:

• Nightly tests
• Weekly security scans
• Database backups
• Dependency checks
• Regular maintenance

Parent-Child Pipeline

A parent pipeline can trigger one or more child pipelines.

This structure works well for large repositories and complex projects.

Multi-Project Pipeline

One project can trigger a pipeline in another project.

For example, a backend release may trigger an integration test project.

---

GitLab Pipeline Statuses

GitLab displays a status for pipelines and jobs.

Common statuses include:

• Created: GitLab created the pipeline or job.
• Pending: The job is waiting for a runner.
• Running: A runner is executing the commands.
• Passed: All required commands completed successfully.
• Failed: A command or required job failed.
• Canceled: A user or system canceled the run.
• Skipped: GitLab did not run the job.
• Manual: The job requires a user to start it.
• Blocked: The pipeline is waiting for a manual action.

Understanding these statuses helps developers troubleshoot pipelines.

---

How to Debug a Failed GitLab Pipeline

A failed pipeline does not always mean the application code is wrong. Configuration, runner, permission, and network problems can also cause failures.

Use the following process:

1. Open the failed pipeline.
2. Select the failed job.
3. Read the final part of the job log.
4. Find the first meaningful error.
5. Identify the command that failed.
6. Run the same command locally.
7. Check variables, permissions, paths, and dependencies.
8. Correct the problem.
9. Commit and push the update.
10. Review the new pipeline.

Common failure reasons include:

• Invalid YAML indentation
• Missing dependencies
• Failed automated tests
• Incorrect file paths
• Unavailable runners
• Missing runner tags
• Expired tokens
• Incorrect environment variables
• Permission errors
• Unsupported software versions
• Missing build tools

GitLab provides a CI Lint feature for validating pipeline configuration. The GitLab YAML reference also lists supported keywords and their behavior.

---

Common GitLab CI/CD Mistakes

Beginners often make a few predictable mistakes.

Incorrect YAML Indentation

YAML depends on whitespace. One incorrectly indented line can make the file invalid.

Using Tabs

Use spaces for indentation because tabs may produce configuration errors.

Adding Secrets to .gitlab-ci.yml

Anyone with repository access may see committed values. Store secrets in GitLab’s protected CI/CD variable settings.

Using Cache for Critical Builds

GitLab may remove or fail to restore caches. Therefore, important output should use artifacts.

Running Every Job on Every Branch

Unnecessary jobs waste time and compute resources. Use rules to control expensive builds and deployments.

Deploying Every Branch to Production

Production deployment should normally depend on protected branches, tags, or manual approval.

Using Unpinned Dependencies

Uncontrolled version changes can break a previously working pipeline. Lock files and stable version references improve consistency.

Ignoring Pipeline Failures

A consistently broken pipeline loses its value. Teams should investigate and fix failures quickly.

Creating One Very Large Job

A large job can be slow and difficult to debug. Smaller jobs provide clearer feedback and allow more parallel work.

---

GitLab CI/CD Security Best Practices

Pipelines can access source code, credentials, servers, and production systems. Therefore, pipeline security requires careful planning.

Follow these practices:

• Protect the main branch
• Require merge-request reviews
• Mask sensitive variables
• Protect production variables
• Restrict runner access
• Use trusted Docker images
• Pin important image and dependency versions
• Review external CI templates
• Limit token permissions
• Rotate credentials regularly
• Avoid printing environment variables
• Separate staging and production secrets
• Require approval for production deployments
• Update self-managed runners
• Review pipeline logs for exposed information
• Use protected environments
• Remove unused runners and variables

Fork-based merge requests require extra attention because untrusted code may attempt to access pipeline resources.

---

Best Practices for Faster Pipelines

A slow pipeline delays feedback and releases.

Use these methods to improve performance:

Run Quick Checks First

Formatting and linting should run before long builds.

Cache Dependencies

Caching avoids downloading unchanged packages repeatedly.

Run Independent Jobs in Parallel

Separate unit tests, integration tests, and analysis when possible.

Use needs

Let jobs start as soon as their required dependencies finish.

Cancel Outdated Pipelines

When a developer pushes a newer commit, an older pipeline may no longer matter. Interruptible jobs and auto-cancel settings can reduce wasted work.

Avoid Rebuilding Unchanged Projects

Rules based on changed files can limit work in monorepositories.

Store Only Necessary Artifacts

Large artifacts increase upload time and storage use.

Use Appropriate Runner Sizes

A job may run slowly when its runner lacks CPU, memory, or disk performance.

---

A Practical GitLab CI/CD Workflow

A reliable project may use the following workflow:

1. A developer creates a feature branch.
2. The developer writes code and tests locally.
3. Code moves to the GitLab repository.
4. GitLab runs formatting, analysis, and unit tests.
5. The developer creates a merge request.
6. A merge-request pipeline performs additional checks.
7. Team members review the code.
8. The merge request enters the main branch.
9. GitLab creates a production-ready build.
10. The pipeline deploys it to staging.
11. Testers verify the application.
12. An authorized user approves production deployment.
13. GitLab deploys the same tested artifact.
14. Monitoring tools track the release.
15. The team rolls back if a serious problem appears.

This process connects code review, automation, testing, and deployment.

---

Frequently Asked Questions

Is GitLab CI/CD free?

GitLab provides CI/CD features across its plans. However, available compute, usage limits, and advanced features may depend on the selected plan and hosting option.

Do I need to install GitLab Runner?

Not always. GitLab.com projects may use available hosted runners. You need to install a runner when you require your own execution environment or use a self-managed setup without a suitable runner.

Where should I put .gitlab-ci.yml?

Place it in the root directory of the repository unless your project uses a configured custom CI/CD file location.

Does GitLab CI/CD require Docker?

No. GitLab Runner supports different executors. However, Docker remains popular because it provides isolated and repeatable environments.

Can GitLab CI/CD deploy Flutter applications?

Yes. It can analyze, test, build, sign, and distribute Flutter applications. Android builds need the Android toolchain, while iOS builds require a suitable macOS runner and Apple signing configuration.

Can GitLab CI/CD deploy websites?

Yes. GitLab can deploy web applications to cloud services, hosting platforms, private servers, Kubernetes, or GitLab Pages.

What happens if a job fails?

GitLab marks the job as failed. Later dependent stages usually stop unless the configuration allows that failure or defines different behavior.

What is the difference between a job and a stage?

A job performs specific commands. A stage groups related jobs and helps control their execution order.

What is the difference between an artifact and a cache?

An artifact stores job output, such as a build or test report. A cache stores reusable files to speed up future work.

Can I run a pipeline manually?

Yes. GitLab allows authorized users to start pipelines and manual jobs from the interface or through supported APIs.

Is .gitlab-ci.yml case-sensitive?

Yes. The default filename is lowercase and case-sensitive. Use .gitlab-ci.yml exactly unless you configure another location.

---

Conclusion

GitLab CI/CD automates the process of checking, testing, building, and deploying software.

The .gitlab-ci.yml file defines the workflow. Pipelines contain jobs, while stages organize those jobs into a logical order. GitLab runners execute the commands and report the results.

A beginner does not need to create a complex deployment system immediately. Start with one job that prints a message. Next, add code analysis and automated tests. After that, create build artifacts and introduce staging deployment. Finally, add secure variables, production approval, monitoring, and rollback support.

A well-designed GitLab CI/CD pipeline reduces repetitive work, detects problems earlier, and creates a consistent release process. Most importantly, it gives developers greater confidence when delivering software to users.