Хранилища кода являются неотъемлемой частью современной разработки ПО. Они позволяют командам разработчиков управлять своим кодом, устанавливать версии и совершенствовать процесс разработки. Современные реалии внесли свои коррективы в работу, заставив в короткие сроки перейти на российские аналоги ПО.

В этой статье Центр цифровой трансформации РТ рассказывает о своем опыте импортозамещения платформы Bitbucket на отечественный софт.

Как всё начиналось

В течение длительного времени мы успешно использовали платформу Bitbucket. Нас привлекало ее удобство интеграции с другими применяемыми в нашей организации продуктами, а также возможность размещения хранилища внутри нашей защищённой инфраструктуры, что обеспечивало соблюдение требований информационной безопасности.

По независящим от нас причинам, продление текущей лицензии Atlassian было ограничено. Произошел уход иностранного софта с российского рынка по политическим причинам, что сильно ускорило процессы импортозамещения – поиска альтернативы и переход на иной репозиторий кода.

Нашим главным приоритетом стал поиск способа минимизирования рисков потери доступа к нашим наработкам и обеспечения продолжения эффективной и привычной работы наших разработчиков.

Опыт применения Bitbucket

В целом, Bitbucket был хорош и удобен, в том числе, за счет интеграции с другими широко используемыми разработчиками, да и не только с ими, но и с продуктами Atlassian, такими как Jira и Confluence. Это позволяло нам удобно взаимодействовать между различными инструментами разработки.

Однако в Bitbucket были и ограничения, которые оказывали влияние на нашу разработку. Например, ограничения в настройке процесса CI/CD и интеграции с инструментами автоматизации могли замедлять процесс развертывания и доставки кода. Некоторые важные функции также требовали покупки платных расширений, что приводило к дополнительным расходам.

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

Накопленный опыт использования Bitbucket помог лучше понять наши потребности и ожидания от репозитория кода.

Первое ожидание от репозитория – это управление доступом. Мы поняли, как важно иметь гибкие настройки доступа к репозиториям на основе ролей и прав к нему, чтобы предотвратить потенциальную утечку кода. Также одним из важных критериев при выборе было удобство работы с кодом. Мы оценили интуитивный интерфейс Bitbucket, его удобство при просмотре и изменении кода, возможности добавлять комментарии и замечания. Это повышает коммуникацию между участниками команды и ускоряет процессы разработки. Еще нам было важно чтобы софт обладал гибкостью и настраиваемостью нашего workflow, включал возможность работы с ветками, pull requests, code reviews и другими функциями для эффективного управления разработкой.

Переход и его плюсы

Нашим выбором, во многих смыслах очевидным, стал Gitlab Community Edition. Для себя мы выделили следующие плюсы:

1. Самый явный для нас плюс в том, что это open-source решение, а значит, отсутствуют проблемы с лицензией. Можно свободно и бесплатно использовать все функции Gitlab CE.

2. Gitlab CE – это инструмент, который может быть настроен под определенные потребности команды, предоставляя гибкость и контроль процесса разработки.

3. Более широкий набор инструментов для автоматизации и DevOps таких как CI/CD pipeline и Kubernetes integration. Это создает комфортные условия для эффективной и быстрой разработки и деплой проектов.

4. Возможность Gitlab CE импортировать репозитории из других различных платформ, таких как Github и Bitbucket, значительно упрощает процесс переноса проектов с одной платформы на другую. Мы делали так: Import your project from Bitbucket Server | GitLab.

5. Конечно, в Bitbucket есть функция мерджа, но в Gitlab CE, на наш взгляд, она реализована более гибко и интуитивно понятнее. Мы можем осуществлять мердж сразу в рамках интерфейса Gitlab CE, а также автоматизировать этот процесс с помощью CI/CD пайплайнов. У нас получилось даже сэкономить немного времени, повысить эффективность и уверенность в качестве продукта.

Трудности и минусы перехода

Во время перехода мы выделили не только плюсы, но и те сложности, с которыми предстоит столкнуться. Для себя отметили следующее:

1. Трудности при переходе на новую систему контроля версий. Чтобы привыкнуть к новым инструментам и рабочим процессам, команде разработчиков нужно потратить время и приложить усилия.

2. Настройка и управление GitLab CE может быть сложной задачей, особенно для команд или организаций без опыта работы с подобными инструментами. Внедрение и настройка GitLab CE может потребовать значительных усилий всей команды и ресурсов для обеспечения его правильной работы.

3. Необходимость перенастройки интеграций и специфичных настроек, работающих из коробки BitBucket. Кроме того, некоторые интеграции могут быть недоступны в GitLab CE. В этом случае может помочь или поиск альтернатив, или хорошие специалисты, готовые реализовать и, главное, поддерживать такие механизмы.

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

Опыт использования Gitlab

Одной из ключевых особенностей GitLab CE, которую мы активно использовали, являются раннеры. Мы настроили и добавили раннеры в нашу инфраструктуру. Это позволило нам выполнять автоматическую сборку, тестирование и развертывание проектов. Раннеры позволяют запускать пайплайны CI/CD и выполнять задачи на различных окружениях, обеспечивая высокую производительность и гибкость в процессе разработки.

Еще одним важным аспектом нашего опыта использования GitLab CE стало внедрение решений для статического анализа кода (SAST), которое работает почти из «коробки» и не требует настройки Static Application Security Testing (SAST) | GitLab. Мы внедрили SAST-инструменты в рамках нашего CI/CD пайплайна, чтобы автоматически сканировать и анализировать код на наличие потенциальных уязвимостей и ошибок. Это позволило нам заблаговременно обнаруживать и исправлять проблемы безопасности и качества кода, тем самым мы повышаем надежность и безопасность наших проектов.

Что сейчас

Помимо внутренних задач нам интересно участвовать в создании и развитии отечественного решения. По этой причине мы решили принять участие в эксперименте минцифры РФ и подали заявку.

Недавно был опубликован приказ минцифры РФ №496 с утвержденным перечнем организаций, принимающих участие в этом эксперименте, и Центр цифровой трансформации РТ оказался в этом списке.

Всего участниками эксперимента являются 62 организации и 20 физических лиц, из Татарстана в перечень попало 4 организации.

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

Для этих целей мы развертываем локальное решение, которое не имеет доступа из Интернета и доступно только ограниченному количеству сотрудников. На него мы планируем размещать коды и документацию по нашим проектам, а также периодически переносить коды из основного репозитория. Это позволит всегда иметь под рукой результаты принятых работ и возможность их предоставления в сжатые сроки.

Такое решение дает возможность значительно меньше переживать о возможных последствиях утраты или порчи основного репозитория. Также это хранилище может быть использовано для небольших локальных работ и контроля наших исполнителей. Для локального репозитория мы выбрали Git как наиболее простое и закрывающее наши ключевые требования решение.

Выводы

Переход с Bitbucket на GitLab Community Edition был важным шагом для нашей команды разработки. Мы оценили ряд преимуществ, которые предоставляет GitLab CE. Это и то, что платформа открыт и бесплатна, и ее возможность гибкой настройки и контроля процессов разработки, а также интеграции с другими инструментами и импорт репозиториев.

Однако мы столкнулись с некоторыми минусами, не упомянуть которые было бы несправедливо. Во-первых, переход на новую платформу потребовал значительных усилий и времени для настройки интеграций и переноса данных. Приходилось прерывать разработку, так как была необходимость приспосабливаться к новым рабочим процессам. Во-вторых, в процессе работы с GitLab Community Edition мы столкнулись с некоторыми ограничениями. Например, некоторые функциональные возможности, которые мы привыкли использовать в Bitbucket, не были доступны изначально или требовали дополнительной настройки. Это потребовало от нас дополнительного времени и усилий для изучения новых возможностей, привыкания к новому интерфейсу и рабочим процессам.

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

Таков наш небольшой опыт использования репозиториев.

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