Мы уже рассказывали о методологии Agile, которая позволяет организовать разработку программного обеспечения. Не менее (а может и более) распространенным подходом сегодня является еще один – DevOps. Он, в отличие от Agile, нацелен на организацию работы команд, создающих софт.

Что такое DevOps

Этому термину как минимум 11 лет. Акроним от слов development и operations впервые прозвучал еще в 2009 году, но часто утверждается, что как подход к разработке программного обеспечения DevOps существует гораздо дольше. Не станем докапываться до истоков. Сегодня DevOps превратился в методологию. Под этим термином одновременно понимаются и подходы к взаимодействию разных специалистов, и интеграция рабочих процессов, и даже отдельная специальность, представители которой формируют единую команду из разработчиков и специалистов поддержки.

DevOps иногда даже путают с Agile – еще одной популярной методологией. Правда, между ними есть одно важное различие. Если Agile нацелен на изменение и практики работы команд разработки, то DevOps больше погружен в процессы и организацию. Более того, популярность DevOps стала прямым следствием распространения agile-подходов, которое привело к увеличению количества версий выпускаемого ПО.

В команде, которая работает над любым серьезным приложением, есть специалисты как минимум двух разных профилей. Одна группа (назовем ее условно разработчиками – Developers) отвечает за создание приложение и его запуск. В обязанности другой входит обеспечение устойчивой работы приложения (Operations). Плохой пример взаимодействия этих разных групп – неработающее приложение, восстановить функциональность которого невозможно никакими силами. 

Каждое из подразделений отвечает за свой участок работы и переводит «стрелки» на незадачливых коллег. Точно такая же ситуация была красочно описана одним из персонажей Аркадия Райкина: «К пуговицам претензии есть?». Что делать для того, чтоб избежать такой неприятной ситуации? Вот в таких случаях как раз и необходим DevOps. С ним ответственность и за разработку, и за работоспособность ПО лежит на всех членах команды, и каждый из них готов подключиться, в случае необходимости, к решению возникшей проблемы.

Инструменты DevOps

Как и для любой методологии, для использования DevOps необходимы специальные инструменты. Увы, но универсального, единственного инструмента, который мог бы полностью обеспечить DevOps-подход, не существует. 

Множество самых разных решений, от Slack и Jira до Asana и Zoom можно назвать DevOps-инструментами, и это будет вполне справедливо. Ведь для того, чтобы реализовать DevOps-подход, необходимы решения для разработки и сборки ПО, автоматизации тестирования, организации выпуска релизов, обеспечения работоспособности, и, наконец, средства для совместной работы внутри отдельных команд и взаимодействия разных команд разработки отдельных продуктов.

Сделать общий обзор всех инструментов DevOps просто невозможно. Каждый их класс требует отдельного рассмотрения. Мы в этот раз коснемся даже не одного класса, а отдельного решения, которое с недавних пор стало доступно клиентам «Системного софта». Речь пойдет об управлении репозиторием – хранилищем тех самых кирпичиков, из которых строятся программные решения.

Хостинг для исходного кода

Любому разработчику конечно же знакомо название GitHub – «социальная сеть для программистов», крупнейший ресурс для хостинга ИТ-проектов и их совместной разработки. Он был основан в 2008 году и стал чрезвычайно популярным и, наконец, крупнейшим в мире ресурсом для девелоперов. Крупнейшим, но не единственным. У GitHub есть альтернатива, о которой сегодня и пойдет речь.

Созвучие названий не должно создавать иллюзии родства. Общие у них только первые части названий, произошедшие от названия распределенной системы управления версиями ПО. GitLab – самостоятельный проект с продолжительной историей. Его создали в 2011 году украинские программисты Валерий Сизов и Дмитрий Запорожец. Сегодня это – компания с миллиардной капитализацией. 

Уже в первые годы своего существования проект разделился на две версии: Community Edition и Enterprise Edition, которые распространяются как свободное программное обеспечение с открытым исходным кодом под лицензией MIT. Отличие версий – в дополнительных возможностях, которые присутствуют в Enterprise Edition.

В числе клиентов GitLab – IBM, Goldman Sachs, Ticketmaster, Drupal, Nvidia, Siemens, Alibaba и NASA. На GitLab хостятся сотни проектов GNOME, и надо полагать, что в ближайшем будущем эта «доска почета» станет еще шире: сегодня проект стал главной альтернативой GitHub после того, как его купила в 2018 году Microsoft.

Главный продукт GitLab – одноименное приложение. Оно предназначено для того, чтобы полностью контролировать весь процесс создания и использования программного обеспечения.

GitLab не зря называют альтернативой GitHub. Сервисы похожи друг на друга, а их функциональность во многом идентична. GitLab позволяет вести проекты, отслеживать ошибки, формировать запросы на добавление кода, вести контроль за изменениями, организовывать навигацию по тегам и веткам.

Доступ к репозиторию осуществляется на основе учетных записей и групп. По сравнению с GitHub подход более строг: если в «соцсети для программистов» разработчики сами определяют, какие именно права доступа предоставляются к отдельным репозиториям, то в GitLab политика доступа формируется на основе ролей участников команд. 

При этом группы могут быть приватными, внутренними и публичными. Более того, существуют и подгруппы, что делает GitLab особенно удобным для крупных компаний, где ведутся сразу несколько проектов или работают несколько подразделений.

Одно из преимуществ GitLab – гораздо более подробная, чем в конкурирующем проекте, документация, которая описывает порядок импорта данных от внешний поставщиков. При этом и источников данных может быть гораздо больше, чем в GitHub.

Доступные версии GitLab

Важное достоинство GitLab – возможность выбора модели использования энтерпрайз-версии сервиса. Он прост: в распоряжении пользователей есть обычная SaaS-версия, которая позволяет начать работу, просто зарегистрировав аккаунт, или специальная, позволяющая разместить решение на собственном сервере или на публичной облачной платформе.

GitLab – классическое публичное облако, в котором заказчик получает готовую систему, не занимаясь ее настройкой. Для тех, кто предпочитает хостить свои проекты на собственных серверах (физических или облачных) или на арендуемой у провайдера платформе, предназначена версия GitLab self-managed.

Отличия версий невелики. В первом случае управление доступом членов команды будет осуществлять тот, кто администрирует зарегистрированный на сервисе аккаунт, во втором раздать доступ будет администратор компании. Кроме того, версия self-managed позволит настраивать сервис индивидуально для каждого пользователя, и выбирать дополнительную функциональность в соответствии с потребностями конкретной группы разработки.