Fedora и CentOS запускают Git Forge. GitLab открывает 18 проприетарных возможностей
31 марта 2020 года
Проекты CentOS и Fedora сообщили о решении по созданию сервиса совместной разработки Git Forge, который будет построен с использованием платформы GitLab. GitLab станет первичной платформой для взаимодействия с Git-репозиториями и для хостинга проектов, связанных с дистрибутивами CentOS и Fedora. Ранее применяемый сервис Pagure продолжит существовать, но будет передан на попечение сообществу, заинтересованному в продолжении разработки. Pagure будет выведен из-под сопровождения трудоустроенной в Red Hat команды CPE (Community Platform Engineering), занимающейся поддержанием инфраструктуры для разработки и публикации релизов Fedora и CentOS.
При оценке возможных решений для нового Git Forge рассматривались Pagure и Gitlab. На основании изучения около 300 отзывов и пожеланий от участников проектов Fedora, CentOS, RHEL и CPE, были сформированы требования к функциональности и сделан выбор в пользу Gitlab. Кроме типовых операций с репозиториями (слияние, создание форков, добавление кода и т.п.) среди ключевых требований были заявлены безопасность, удобство работы и стабильность платформы.
В число требований вошли такие возможности, как отправка push-запросов по HTTPS, средства ограничения доступа к веткам, поддержка приватных веток, разделение доступа внешних и внутренних пользователей (например, для работы над устранением уязвимостей во время эмбарго на раскрытие сведений о проблеме), привычность интерфейса, унификация подсистем для работы с сообщениями о проблемах, кодом, документацией и планированием новых возможностей, наличие средств для интеграции с IDE, поддержка типовых рабочих процессов.
Из возможностей GitLab, которые окончательно повлияли на принятие решения по выбору данной платформы, упомянуты поддержка подгрупп с выборочным доступом к репозиториям, возможность использования бота для автоматических слияний (требуется CentOS Stream для поддержании пакетов с ядром), наличие встроенных средств для планирования разработки, возможность использования готового SAAS-сервиса с гарантируемым уровнем доступности (позволит высвободить ресурсы на поддержание серверной инфраструктуры).
Решение уже вызвало критику среди разработчиков, связанную с тем, что решение было принято без предварительного широкого обсуждения. Также были высказаны опасения, что сервис не будет использовать свободную Comminity-редакцию GitLab. В частности, возможности, необходимые для реализации описанных в анонсе требований к Git Forge, доступны только в проприетарной версии GitLab Ultimate.
Критике также подверглось намерение воспользоваться предоставляемым компанией GitLab сервисом SAAS (приложение как сервис), вместо развёртывания GitLab на своих серверах, что выводит сервис из под контроля (например, невозможно быть уверенным, что все уязвимости в системе оперативно устраняются, должным образом поддерживается инфраструктура, в один прекрасный момент не будет навязана телеметрия и исключена диверсия со стороны персонала сторонней компании). Решение также не сочетается с основополагающими принципами Fedora, в которых определено, что проект должен отдавать предпочтения свободным альтернативам.
Тем временем, компания GitLab объявила об открытии реализаций 18 функциональных возможностей, ранее предлагавшихся только в проприетарных редакциях GitLab. Возможности охватывают различные области управления полным циклом разработки ПО, включая планирование разработки, создание проектов, верификацию, работу с пакетами, формирование релизов, настройку и защиту.
В число свободных переведены следующие функции:
- Прикрепление связанных issue;
- Экспорт issue из GitLab в CSV;
- Режим планирования, упорядочивания и визуализации процесса разработки отдельных функциональных возможностей или релизов;
- Встроенная сервисная служба для связывания участников проекта со сторонними лицами при помощи email;
- Web-терминал для Web IDE;
- Возможность синхронизации файлов для тестирования изменений в коде в web-терминале;
- Средства управления дизайном, позволяющие загружать в issue макеты и ресурсы, используя issue как единую точку доступа ко всему, что требуется для разработки новой возможности;
- Отчёты о качестве кода;
- Поддержка пакетных менеджеров Conan (C/C++), Maven (Java), NPM (node.js) и NuGet (.NET);
- Поддержка канареечных развёртываний, позволяющих установить новую версию приложения на небольшой части систем;
- Инкрементальные распространения, позволяющие вначале доставить новые версии лишь для небольшого числа систем, постепенно доводя охват до 100%;
- Флаги активации функциональности, дающие возможность поставлять проект в различных редакциях, динамически активируя определённые возможности;
- Обзорный режим развёртываний, позволяющий оценить состояние каждого окружения непрерывной интеграции на базе Kubernetes;
- Поддержка определения нескольких кластеров Kubernetes в конфигураторе (например, можно использовать отдельные кластеры Kubernetes для пробных внедрений и рабочих нагрузок);
- Поддержка определения политик сетевой безопасности контейнеров, позволяющих разграничить доступ между подами Kubernetes.
Дополнительно можно отметить публикацию обновлений GitLab 12.9.1, 12.8.8 и 12.7.8 (Community Edition и Enterprise Edition), в которых устранена уязвимость. Проблема проявляется начиная с выпуска GitLab EE/CE 8.5 и позволяет прочитать содержимое любого локального файла при перемещении issue между проектами. Детали об уязвимости будут раскрыты через 30 дней.
Источники
[править]Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии[править]
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.