Собственный репозиторий GitLab
Собственный репозиторий GitLab
Что такое репозиторий и для чего он нужен?
Репозиторий - место, где хранятся и обслуживаются данные, в нашем случае файлы проектов, он предоставляет единый интерфейс к самим данным и их версиям.
Здесь формируются команды разработки и настраиваются роли - кто может читать проект, кто присылать изменения, а кто принимать их в дерево проекта.
У каждого разработчика есть свой локальный репозиторий, где он работает с ветками, коммитами и состояниями, но для работы команды нужен удаленный репозиторий, который принимает, хранит и раздает данные централизованно.
Естественно такая инфраструктурная единица становится важным звеном производства и образовывает вокруг себя экосистему. Современные продукты предоставляют множество решений в дополнение к базовым возможностям репозиториев.
Это управление пользователями, проектами, группами, задачами, средами развертывания, коммуникацией, code-review и средствами автоматизации. Всё вместе это называется "Платформой разработки" (Development Platform).
Главной такой платформой, предоставляющей услуги по модели SaaS можно назвать GitHub. Здесь есть бесплатные публичные репозитории для всех желающих и приватные, доступные по платной подписке. Чаще всего в руководствах и примерах можно встретить работу именно с этой платформой, но есть и другие решения и мы для себя выбрали GitLab.
Почему GitLab?
Разработчики GitLab стараются создать лучший инструментарий и сделать его максимально доступным даже в бесплатной версии (Core, бывшая Community Edition). Они ведут активную разработку, открыты сообществу и, что самое важное, предоставляют self-managed версию для размещения коробочного продукта на собственном сервере.
Модель Saas удобна, но в этом случае приходится целиком полагаться на провайдера. Во время сбоев, неполадок или проблем с доступностью (которые случатся обязательно) ваша инфраструктура будет недоступна. В критичный момент это может сильно подвести и при работе с десятками и сотнями проектов, собственный сервер выглядит более оправданным.
Вторым важным фактором является приватность ваших данных - вы размещаете их не "где-то" на чужой совести, а у себя и уверены в том, что доступ к данным имеете только вы (при условии грамотного администрирования конечно же).
Системные требования
Современная производственная платформа - это сложный комплекс технических средств и служебных процессов, тем не менее для комфортной работы GitLab достаточно вполне бюджетного сервера.
Официальная документация рекомендует два процессорных ядра и 8 Гб оперативной памяти для комфортной работы 100-500 пользователей.
Наш сервер имеет конфигурацию 4 x 2,4+ ГГц и 4 Гб + SSD, GitLab на ней работает отлично.
Базовые возможности
GitLab позволяет гибко формировать команды разработки.
Сотрудники распределяются по группам и базово наследуют права от них, но при необходимости права можно настроить индивидуально под проект.
GitLab собирает множество метрик, активность разработчиков одна из них.
Запросы на слияние (Merge Requests).
Разработчики не могут самостоятельно вливать изменения в исходный код проекта, они могут их только предложить. Задача тимлида - оценить решение, проверить код, обсудить доработки и в итоге пропустить или отклонить изменения.
Как видно на скриншоте выше, разработчик прислал пакет изменений из двух коммитов и 22 изменений (вкладки Commits и Changes).
Локальная ветка разработчика, предложенная к вливанию в master, отстает на 600 коммитов (старый неактуальный MR, который я специально для демонстрации придержал). Ветка содержит изменения, конфликтующие с изменениями в целевой ветке, это называется Merge Conflicts.
При обычной работе с консолью, требуется провести довольно сложные манипуляции с git и файлами, чтобы разрешить возникшие конфликты, GitLab предоставляет умный интерфейс для этого:
Вся история коммитов и слияний доступна в виде наглядного графа с возможностью прыгнуть в нужный коммит, как бы давно он не был сделан, и продолжить работу с проектом от этого состояния.
Управление проектом часто требует оперативных действий, когда каждая минута на счету и некогда переключаться между инструментами, а порой кроме браузера у вас под рукой ничего и нет. На этот случай в GitLab есть полноценная IDE:
Если нам надо разобраться в потоке изменений и выявить ответственного за конкретные изменения сотрудника, для этого есть команда blame от git, для которой GitLab предоставляет удобный интерфейс:
Continuous Integration
Непрерывная интеграция - это инструменты автоматизации, призванные обеспечить ваше производство сборочными линиями. Весь процесс тестирования, сборки и доставки изменений можно автоматизировать.
Например, у нас есть превью-площадка для тестирования и продакшен.
За тестовой площадкой закрепляем ветку develop, за продакшеном master.
Разработчики отправляют изменения в develop, тимлид их проверяет и пропускает в ветку, как только изменения вливаются, срабатывает сборочная линия, изменения выкатываются на превью-площадку.
После проверки тестовой сборки мы вливаем ветку develop в master и вот уже срабатывает сборочная линия для продакшена.
Мы не подключаемся к площадкам, не вводим никаких команд, процесс развертывания автоматизирован, мы работаем только с GitLab. Это быстрее, это надежнее, это позволяет снизить нагрузку от администрирования и сосредоточиться на важном. Когда в работе десятки проектов с десятками площадок и десятки разработчиков постоянно присылают изменения, процесс сборки и доставки изменений требует постоянного участия и фактически отдельной должности, при этом человеческий фактор никто не отменял.
Сборочные линии позволяют разделить этапы разработки, сборки и доставки, оставляя разработчикам только разработку, а руководителям только управление. Это возможность масштабироваться в рамках имеющихся ресурсов.
Мы можем быть спокойны за наш конвейер, в случае неудачи на любом из этапов сценарий будет прерван, а руководитель получит наглядное уведомление:
Мобильность
GitLab хорошо адаптирован к мобильным устройствам.
Находясь в дороге, имея под рукой лишь смартфон, руководитель может полноценно участвовать в рабочем процессе.
Получил на почту уведомление о срочном исправлении? - заходим в GitLab, подтверждаем Merge Request, запускаются сборочные линии и через пару минут изменения доставлены на продакшн.
Алексей Андросов
Руководитель отдела веб-разработки
- Что такое репозиторий и для чего он нужен?
- Почему GitLab?
- Системные требования
- Базовые возможности
- Continuous Integration
- Мобильность
Что такое репозиторий и для чего он нужен?
Репозиторий - место, где хранятся и обслуживаются данные, в нашем случае файлы проектов, он предоставляет единый интерфейс к самим данным и их версиям.
Здесь формируются команды разработки и настраиваются роли - кто может читать проект, кто присылать изменения, а кто принимать их в дерево проекта.
У каждого разработчика есть свой локальный репозиторий, где он работает с ветками, коммитами и состояниями, но для работы команды нужен удаленный репозиторий, который принимает, хранит и раздает данные централизованно.
Естественно такая инфраструктурная единица становится важным звеном производства и образовывает вокруг себя экосистему. Современные продукты предоставляют множество решений в дополнение к базовым возможностям репозиториев.
Это управление пользователями, проектами, группами, задачами, средами развертывания, коммуникацией, code-review и средствами автоматизации. Всё вместе это называется "Платформой разработки" (Development Platform).
Главной такой платформой, предоставляющей услуги по модели SaaS можно назвать GitHub. Здесь есть бесплатные публичные репозитории для всех желающих и приватные, доступные по платной подписке. Чаще всего в руководствах и примерах можно встретить работу именно с этой платформой, но есть и другие решения и мы для себя выбрали GitLab.
Почему GitLab?
Разработчики GitLab стараются создать лучший инструментарий и сделать его максимально доступным даже в бесплатной версии (Core, бывшая Community Edition). Они ведут активную разработку, открыты сообществу и, что самое важное, предоставляют self-managed версию для размещения коробочного продукта на собственном сервере.
Модель Saas удобна, но в этом случае приходится целиком полагаться на провайдера. Во время сбоев, неполадок или проблем с доступностью (которые случатся обязательно) ваша инфраструктура будет недоступна. В критичный момент это может сильно подвести и при работе с десятками и сотнями проектов, собственный сервер выглядит более оправданным.
Вторым важным фактором является приватность ваших данных - вы размещаете их не "где-то" на чужой совести, а у себя и уверены в том, что доступ к данным имеете только вы (при условии грамотного администрирования конечно же).
Системные требования
Современная производственная платформа - это сложный комплекс технических средств и служебных процессов, тем не менее для комфортной работы GitLab достаточно вполне бюджетного сервера.
Официальная документация рекомендует два процессорных ядра и 8 Гб оперативной памяти для комфортной работы 100-500 пользователей.
Наш сервер имеет конфигурацию 4 x 2,4+ ГГц и 4 Гб + SSD, GitLab на ней работает отлично.
Базовые возможности
GitLab позволяет гибко формировать команды разработки.
Сотрудники распределяются по группам и базово наследуют права от них, но при необходимости права можно настроить индивидуально под проект.
GitLab собирает множество метрик, активность разработчиков одна из них.
Запросы на слияние (Merge Requests).
Разработчики не могут самостоятельно вливать изменения в исходный код проекта, они могут их только предложить. Задача тимлида - оценить решение, проверить код, обсудить доработки и в итоге пропустить или отклонить изменения.
Как видно на скриншоте выше, разработчик прислал пакет изменений из двух коммитов и 22 изменений (вкладки Commits и Changes).
Локальная ветка разработчика, предложенная к вливанию в master, отстает на 600 коммитов (старый неактуальный MR, который я специально для демонстрации придержал). Ветка содержит изменения, конфликтующие с изменениями в целевой ветке, это называется Merge Conflicts.
При обычной работе с консолью, требуется провести довольно сложные манипуляции с git и файлами, чтобы разрешить возникшие конфликты, GitLab предоставляет умный интерфейс для этого:
Вся история коммитов и слияний доступна в виде наглядного графа с возможностью прыгнуть в нужный коммит, как бы давно он не был сделан, и продолжить работу с проектом от этого состояния.
Управление проектом часто требует оперативных действий, когда каждая минута на счету и некогда переключаться между инструментами, а порой кроме браузера у вас под рукой ничего и нет. На этот случай в GitLab есть полноценная IDE:
Если нам надо разобраться в потоке изменений и выявить ответственного за конкретные изменения сотрудника, для этого есть команда blame от git, для которой GitLab предоставляет удобный интерфейс:
Continuous Integration
Непрерывная интеграция - это инструменты автоматизации, призванные обеспечить ваше производство сборочными линиями. Весь процесс тестирования, сборки и доставки изменений можно автоматизировать.
Например, у нас есть превью-площадка для тестирования и продакшен.
За тестовой площадкой закрепляем ветку develop, за продакшеном master.
Разработчики отправляют изменения в develop, тимлид их проверяет и пропускает в ветку, как только изменения вливаются, срабатывает сборочная линия, изменения выкатываются на превью-площадку.
После проверки тестовой сборки мы вливаем ветку develop в master и вот уже срабатывает сборочная линия для продакшена.
Мы не подключаемся к площадкам, не вводим никаких команд, процесс развертывания автоматизирован, мы работаем только с GitLab. Это быстрее, это надежнее, это позволяет снизить нагрузку от администрирования и сосредоточиться на важном. Когда в работе десятки проектов с десятками площадок и десятки разработчиков постоянно присылают изменения, процесс сборки и доставки изменений требует постоянного участия и фактически отдельной должности, при этом человеческий фактор никто не отменял.
Сборочные линии позволяют разделить этапы разработки, сборки и доставки, оставляя разработчикам только разработку, а руководителям только управление. Это возможность масштабироваться в рамках имеющихся ресурсов.
Мы можем быть спокойны за наш конвейер, в случае неудачи на любом из этапов сценарий будет прерван, а руководитель получит наглядное уведомление:
Мобильность
GitLab хорошо адаптирован к мобильным устройствам.
Находясь в дороге, имея под рукой лишь смартфон, руководитель может полноценно участвовать в рабочем процессе.
Получил на почту уведомление о срочном исправлении? - заходим в GitLab, подтверждаем Merge Request, запускаются сборочные линии и через пару минут изменения доставлены на продакшн.
Алексей Андросов
Руководитель отдела веб-разработки
16 МАРТА / 2018