GitLab

GitLab was founded in 2011 in San Francisco, California by Dmitriy Zaporozhets and Sid Sijbrandij. It is a platform designed to accelerate software development processes, detect errors at early stages, and automate workflows. GitLab is an open source and integrated DevOps platform that encompasses all stages of the software development lifecycle. It unifies operations such as implementing core DevOps methodologies like Continuous Integration (CI) and Continuous Deployment (CD), automating security testing, and managing container orchestration within a single system.

GitLab’s architecture is designed to support the DevSecOps approach, which integrates software security alongside DevOps methodologies. This platform enables development teams to work more efficiently while aiming to accelerate software processes enhance their security and quality.

GitLab is built on the Git version control system. Users can directly perform functions such as branching, merging (merge requests), commit history and code review through the GitLab interface. This facilitates asynchronous and secure code development processes for teams.

GitLab CI/CD supports automatic testing, building and deployment pipelines after every commit. Pipeline definitions can be easily created using a YAML-based gitlab-ci.yml file. GitLab Runners are agents that execute these processes and can be deployed on both local and Kubernetes environments.

• Issue tracking system
• Kanban boards
• Milestone-based release planning
• Automatic version numbering and tagging

GitLab provides comprehensive tools not only for developers but also for product and project managers.

GitLab integrates software security into every stage of the development lifecycle:

• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)
• Container Scanning
• License Compliance

These security tests can be automatically triggered through pipelines.

GitLab’s flexible and scalable architecture enables large organizations to manage high-traffic software workflows. The following components form the foundation of this architecture:

GitLab Rails: The core service of GitLab. It is the main component that manages the web interface, REST API and numerous backend services. The majority of user interactions occur at this layer.

PostgreSQL: The relational database management system used by GitLab. All user data project metadata version history and configuration details are stored here.

Redis: A high-speed in-memory data store used for session management caching and job queue handling. It is critical to GitLab’s performance.

Sidekiq: A worker system configured to manage background jobs. Tasks requiring scheduling such as email notifications and pipeline triggers are executed through this structure.

Nginx: A reverse proxy server that routes incoming HTTP and HTTPS requests to GitLab components. It also terminates TLS encryption traffic.

Gitaly: A specialized backend service that centrally executes Git repository operations. Git operations such as cloning pulling and merging are performed efficiently by Gitaly.

GitLab Workhorse: A proxy server operating at the HTTP layer. It optimizes operations such as large file uploads API request routing and content transformation while relieving the main Rails application of load.

Prometheus + Grafana: Observability tools used to monitor GitLab’s system resources and performance metrics. Prometheus collects data while Grafana visualizes and analyzes it.

GitLab also provides reference architectures in which these components can be distributed horizontally. Based on requirements for high availability (HA) and load balancing PostgreSQL clusters Gitaly servers and CI Runner nodes can be deployed separately.

The architectural diagram below provides a detailed view of GitLab’s monolithic yet modular structure illustrating how system components interact with each other. GitLab’s architecture demonstrates how HTTP/SSH requests from users are processed by internal system components (Rails Redis PostgreSQL Gitaly etc.). This structure enhances developer productivity while enabling high availability and performance goals. (https://panlw.github.io/15365441001781.html)

^{Gitlab Uygulama Mimarisi-}

NGINX

• All incoming HTTP (80) and HTTPS (443) requests to the GitLab system are first handled by NGINX.
• NGINX acts as a reverse proxy and routes incoming traffic to the GitLab Workhorse component.
• TLS termination is also performed at this layer.

GitLab Shell

• Git operations performed by users via SSH (TCP 22) are managed directly through GitLab Shell.
• GitLab Shell serves as an interface that authenticates client requests and forwards them to the Rails application.

GitLab Workhorse

• An intermediate layer that optimizes the processing of requests received from NGINX.
• Handles tasks such as large file uploads preprocessing of API calls and content caching.
• When necessary forwards requests directly to Unicorn (or in modern setups Puma).

Unicorn (GitLab Rails)

• The server that executes GitLab’s core application logic. It hosts the REST API endpoints and web interface.
• Functions such as the user interface project management issue tracking and pipeline triggers occur at this layer.
• Redis and PostgreSQL are continuously interacted with.

Redis

• Used for both caching and job queue management.
• Components such as GitLab Workhorse Unicorn Sidekiq and Gitaly exchange data with Redis.
• Redis is critical for managing user sessions and queuing workloads.

PostgreSQL

• All structural and user data for GitLab is stored in the PostgreSQL relational database.
• Projects commit history user information and metadata are maintained here.
• The Rails server connects directly to this database.

Sidekiq

• The component that processes background jobs.
• Email notifications webhook triggers scheduled tasks and CI processes are executed here.
• Retrieves and processes jobs queued via Redis.

Gitaly

• The specialized component responsible for GitLab’s source code management.
• All Git operations (cloning push/pull diff blame etc.) are managed through the Gitaly server.
• It operates as a separate layer for efficiency and integrates with GitLab Rails.

Auxiliary Services

GitLab Pages (TCP 8090)

• GitLab includes the GitLab Pages component which supports publishing static content from projects.
• For example documents built with Jekyll or Hugo can be published on this server.
• Requests are routed to the Pages server via NGINX.

GitLab provides full support for Docker-based development and deployment workflows. Users can create manage and integrate their own container registry through GitLab. This reduces external dependencies and ensures processes are conducted within a closed secure environment.

Due to its open source nature GitLab has a rich educational and documentation infrastructure. GitLab University offers interactive learning paths on topics ranging from CI fundamentals to advanced pipeline structures.

• University of Zurich (Vassallo 2020): GitLab has been documented as being used for continuous integration and feedback systems in student projects.
• OSTI & DOE (U.S. Department of Energy): GitLab is actively used to maintain version control and code integrity for energy systems software.
• Springer (2020): GitLab is cited among recommended systems for controlling data analytics pipelines in scientific research.

GitLab is a fully integrated DevOps platform capable of meeting modern software development needs. While version control CI/CD security monitoring and collaboration are all provided within a single framework its open source structure customizability and enterprise compatibility enable it to serve organizations of all sizes.

GitLab’s modular architecture and high scalability capacity provide an ideal foundation for the future of automated software production processes.