Русский
Русский
English
Статистика
Реклама

Системы управления версиями

Перевод 6 лучших практик для безопасного управления Git-репозиториями

04.07.2020 12:05:52 | Автор: admin
Избегайте захламления репозиториев и других действий, которые усложняют управление кодовой базой. Вместо этого используйте лучшие практики, которые помогут упростить работу.



Изучение исходников в репозитории позволяет оценить уровень безопасности приложений. Но если никто не смотрит на код, проблемы будут только расти. К счастью, у GitHub есть свои специалисты по безопасности, которые недавно обнаружили трояна в нескольких репозиториях Git. Его почему-то не заметили сами владельцы этих репозиториев. Хотя мы не можем диктовать другим людям, как управлять своими собственными хранилищами, мы можем учиться на их ошибках. В этой статье мы рассмотрим полезные приёмы работы с репозиториями.


Изучите свой репозиторий




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

Старайтесь не добавлять бинарники




Git изначально заточен под текстовые файлы, будь то код на C, Python или Java, или JSON, YAML, XML, Markdown, HTML и так далее:

$ cat hello.txtThis is plain text.It's readable by humans and machines alike.Git knows how to version this.$ git diff hello.txtdiff --git a/hello.txt b/hello.txtindex f227cc3..0d85b44 100644--- a/hello.txt+++ b/hello.txt@@ -1,2 +1,3 @@ This is plain text.+It's readable by humans and machines alike. Git knows how to version this.


Git не любит бинарные файлы:

$ git diff pixel.pngdiff --git a/pixel.png b/pixel.pngindex 563235a..7aab7bc 100644Binary files a/pixel.png and b/pixel.png differ$ cat pixel.pngPNGIHDR7n$gAMA              abKGDtIME                          -2RIDAc`!3%tEXtdate:create2020-06-11T11:45:04+12:00r.%tEXtdate:modify2020-06-11T11:45:0


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

Что ещё хуже, вы сами не можете проверить (прочитать и проанализировать) двоичные данные.
В дополнение к обычным инструментам POSIX вы можете найти двоичные файлы, используя git diff. Когда вы попытаетесь запустить команду diff с параметром --numstat, Git вернёт нулевой результат:

$ git diff --numstat /dev/null pixel.png | tee-     -   /dev/null => pixel.png$ git diff --numstat /dev/null file.txt | tee5788  0   /dev/null => list.txt


Если вы-таки рассматриваете возможность добавления бинарных файлов в свой репозиторий, остановитесь и подумайте. Если некий двоичный файл генерируется в процессе сборки, то зачем добавлять его в свой репо? Если вы всё же решите, что имеет смысл сделать это, убедитесь, что вы в файле README или аналогичном месте описали, почему храните бинарники и каков протокол их обновления. Обновления должны выполняться экономно, поскольку при каждом изменении, которое вы вносите в двоичный объект, пространство для его хранения удваивается.

Сторонние библиотеки должны оставаться сторонними


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

Для управления внешними зависимостями используйте Git Submodule.

Не используйте git add вслепую




Если ваш проект успешно скомпилирован, не поддавайтесь желанию использовать команду git add. (где . это текущий каталог например). Это особенно важно, если вы не компилируете свой проект вручную, а используете IDE для управления своим проектом. Может быть чрезвычайно сложно отследить, что было добавлено в ваш репозиторий, когда вашим проектом управляет IDE. Поэтому важно добавлять только то, что вы сами создали и подготовили для добавления, а не какой-либо новый объект, который загадочным образом появился в папке вашего проекта.

Так что, прежде чем запускать git add, просмотрите, что будет добавлено в репозиторий. Если вы видите незнакомый объект, выясните, откуда он и почему он всё ещё находится в каталоге вашего проекта после выполнения команды make clean (или эквивалентной команды).

Используйте Git ignore




Типичный каталог любого проекта содержит множество скрытых файлов, метаданных и ненужных артефактов. Вам лучше игнорировать эти объекты: чем больше их будет, тем больше вероятность того, что вам будет мешать этот мусор и вы пропустите что-то важное или опасное.

Файл gitignore даёт возможность отфильтровать лишнее. Github.com/github/gitignore предлагает несколько специально созданных шаблонов gitignore, которые вы можете загрузить и разместить в своём проекте. Gitlab.com, например, предлагал такие шаблоны ещё несколько лет назад.

Модерируйте изменения кодовой базы




Когда вы получаете запрос на слияние или pull-запрос, либо вам присылают патч по электронной почте, вам стоит убедиться, что там всё нормально. Ваша задача изучить новый код, поступающий в вашу кодовую базу, и понять, что он делает. Если вы не согласны с его реализацией или, что ещё хуже, не понимаете эту реализацию, напишите отправителю сообщение и попросите разъяснений. Нет ничего зазорного в том, чтобы изучать новый код, который претендует на место в вашем проекте. Более того, вы делаете это на благо ваших пользователей: они в этом случае будут чётко понимать, какие изменения вы принимаете и почему.

Возьмите на себя ответственность


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



На правах рекламы


Эпичные серверы это виртуальные серверы на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрыми NVMe дисками Intel. Расходятся, как горячие пирожки!

Подробнее..

Перевод Как мы устранили редкую ошибку, из-за которой пришлось разлогинить всех пользователей Github

24.03.2021 10:15:26 | Автор: admin

8 марта мы рассказали о том, что из соображений безопасности разлогинили всех пользователей GitHub.com из-за редкой уязвимости защиты. Мы считаем, что прозрачность ключевой фактор сохранения доверия со стороны пользователей, поэтому решили рассказать об этом баге подробнее. В этом посте мы изложим технические детали данной уязвимости и объясним, как она возникла, как мы на неё отреагировали и какие мы предприняли шаги для того, чтобы подобное не повторилось.

Отчёты пользователей


2 марта 2021 через службу технической поддержки мы получили отчёт пользователя, который войдя на GitHub.com под собственными идентификационными данными, внезапно авторизировался как другой пользователь. Он немедленно вышел из аккаунта, но сообщил о проблеме нам, поскольку она обеспокоила его, и на то были все основания.

Мы привели в действие свои процедуры реагирования на инциденты с безопасностью и немедленно изучили этот отчёт, призвав на помощь специалистов компании из отделов безопасности, разработки и поддержки пользователей. Спустя несколько часов после первого отчёта мы получили второй отчёт от другого пользователя с очень похожей ситуацией. После анализа логов запросов и аудита мы смогли подтвердить истинность полученных внешних отчётов сессия пользователя действительно внезапно оказалась общей для двух IP-адресов примерно во время отправления отчётов.

Исследование недавних изменений в инфраструктуре


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

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

Исследование недавних изменений в коде


Благодаря тому, что мы начали расследование с недавних изменений в инфраструктуре, нам удалось выяснить, что запросы, приводившие к возврату неправильной сессии, обрабатывались на одной и той же машине и в одном процессе. Мы используем многопроцессную схему с веб-сервером Unicorn Rack, выполняющим наше основное Rails-приложение. обрабатывающее такие задачи, как отображение issues и пул-реквестов.

После изучения логов мы выяснили, что тело HTTP-объекта в передаваемом нами ответе клиенту было правильным, ошибочным были только куки в ответе пользователю. Отправившие отчёты об ошибке пользователи получили куки сессии пользователя, запрос которого совсем незадолго до них обрабатывался внутри того же процесса. В одном из случаев два запроса обрабатывались последовательно, один за другим. Во втором случае между ними было ещё два запроса.

У нас появилась рабочая теория о том, что нечто каким-то образом приводило к утечке состояния между запросами, которые обрабатывались в одном процессе Ruby. Нам нужно было выяснить, как такое может происходить.

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

Безопасность потоков и отчёты об ошибках


Для понимания проблемы с безопасностью потоков необходим контекст. Основное приложение, обрабатывающее большинство браузерных взаимодействий на GitHub.com это приложение Ruby on Rails, известное тем, что оно имело компоненты, написанные без учёта возможности в нескольких потоках (т.е. они были непотокобезопасны). Обычно в прошлом непотокобезопасное поведение могло приводить к неправильному значению во внутренних отчётах об исключениях системы, но при этом пользователи не сталкивались с изменением поведения системы.

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

Изначально мы думали, что это только внутренняя проблема отчётности, и что мы будем наблюдать в логах данные, зафиксированные от не относящегося к делу запроса в фоновом потоке. Несмотря на противоречивость, мы посчитали такое поведение безопасным, поскольку каждый запрос имел собственные данные запроса, а Rails-приложение создавало новый экземпляр объекта-контроллера для каждого запроса. Нам по-прежнему было непонятно, как это могло вызывать проблемы, с которыми мы столкнулись.

Многократно используемый объект


Наша команда совершила прорыв, обнаружив, что HTTP-сервер Unicorn Rack, используемый в нашем Rails-приложении, не создаёт новый и отдельный объект env для каждого запроса. Вместо этого он выделяет единственный Ruby Hash, который очищается (с помощью Hash#clear) между запросами, которые он обрабатывает. Благодаря этому мы поняли, что проблема с потокобезопасностью в логгинге исключений может привести не только к неправильности фиксируемых в исключениях данных, но и к передаче данных запросов на GitHub.com.

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


  1. В потоке обработки запросов запускается анонимный запрос (назовём его Request #1). Он регистрирует обратный вызов в текущем контексте для внутренней библиотеки отчётности об исключениях. Обратные вызовы содержат ссылки на текущий объект контроллера Rails, имеющий доступ к единому объекту среды запроса Rack, предоставляемого сервером Unicorn.
  2. В фоновом потоке возникает исключение. Сообщение об исключении копирует текущий контекст, чтобы включить его в отчёт. Этот контекст содержит обратные вызовы, зарегистрированные запросом Request #1, в том числе и ссылку на единую среду Rack.
  3. В основном потоке запускается новый запрос залогиненного пользователя (Request #2).
  4. В фоновом потоке система отчётности об исключениях обрабатывает обратные вызовы контекста. Один из обратных вызовов считывает идентификатор сессии пользователя, но поскольку запрос на момент контекста не имеет авторизации, эти данные ещё не считываются, и, следовательно, запускают новый вызов к системе авторизации через контроллер Rails из запроса Request #1. Этот контроллер пытается выполнить авторизацию и получает куки сессии из общей среды Rack. Так как среда Rack это общий объект для всех запросов, контроллер находит куки сессии запроса Request #2.
  5. В основном потоке запрос Request #2 завершается.
  6. Запускается ещё один запрос залогиненного пользователя (Request #3). В этот момент Request #3 завершает свой этап авторизации.
  7. В фоновом потоке контроллер завершает этап авторизации, записывая куки сессии в cookie jar, находящийся в среде Rack. На данном этапе это cookie jar для Request #3!
  8. Пользователь получает ответ на запрос Request #3. Но cookie jar был обновлён данными куки сессии Request #2, то есть пользователь теперь авторизован как пользователь из Request #2.

Подведём итог: если исключение возникло именно в нужный момент и если параллельная обработка запросов происходит именно в нужном порядке среди серии запросов, то в результате сессия одного запроса заменяется сессией более раннего запроса. Возврат неправильного куки происходит только для заголовка куки сессии, и, как говорилось выше, остальная часть тела ответа, например HTML, по-прежнему была связана с ранее авторизованным пользователем. Это поведение соответствовало с тем, что мы видели в логах запросов и мы смогли чётко идентифицировать все элементы, составлявшие первопричину состояния гонки.

Для возникновения этого бага требовались очень конкретные условия: фоновый поток, общий контекст исключения между основным потоком и фоновым потоком, обратные вызовы в контексте исключения, многократное использование объекта env между запросами и наша система авторизации. Подобная сложность является напоминанием о многих из пунктов, представленных в статье How Complex Systems Fail, и демонстрирует, что для возникновения подобного бага требуется множество различных сбоев.

Предпринимаем действия


Выявив первопричину, мы немедленно сделали основным приоритетом устранение двух условий, критически важных для появления этого бага. Во-первых, мы избавились от нового фонового потока, появившегося после вышеупомянутой модернизации архитектуры, призванной повысить производительность. Благодаря тому, что мы точно знали, что было добавлено в процессе этой работы, изменения легко можно было откатить. Изменение, в котором был удалён этот поток, вывели в продакшен 5 марта. После этого изменения мы знали, что условия, требуемые для возникновения условия гонки, больше не будут удовлетворяться, и что наша непосредственный риск возврата неверных сессий снижен.

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

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

В конце мы решили сделать ещё одно превентивное действие, чтобы гарантировать безопасность данных наших пользователей, и аннулировали все активные сессии пользователей на GitHub.com. Учитывая редкость условий, необходимых для возникновения этого условия гонки, мы знали, что вероятность возникновения бага очень мала. Хотя наш анализ логов, проведённый с 5 по 8 марта, подтвердил, что это была редкая проблема, мы не могли исключить вероятность того, что сессия была неверно возвращена, но никогда не использовалась. Мы не хотели идти на такой риск, учитывая потенциальный ущерб использования даже одной из таких неверно возвращённых сессий.

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

Продолжаем работу


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

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

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

Подведём итог


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

Если взглянуть со стороны, то данный баг не только оказался сложным с технической точки зрения (ведь для его возникновения требуются сложные взаимодействия между несколькими потоками, отложенными обратными вызовами и совместным использованием объектов), но и стал проверкой способности нашей организации реагировать на проблему с неизвестной причиной и уровнем угрозы. Отлаженная работа команды реагирования на инциденты с безопасностью совместно со специалистами из отделов поддержки, безопасности и разработки позволила нам быстро исследовать, оценить и квалифицировать потенциальную опасность этой проблемы, а также повысить приоритет её решения во всей компании. Это повышение приоритета ускорило работу над анализом логов, изучением последних изменений в коде и архитектуре, а в конечном итоге позволило выявить глубинные проблемы, которые привели к возникновению этого бага.

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

Перевод Автоматизация семантического управления версиями с помощью Maven (SemVer GitFlow Maven)

05.10.2020 10:14:40 | Автор: admin

Вы используете семантический подход к управлению версиями? Вы используете gitflow? Скорее всего, вы знакомы с процессом корректировки версий, создания веток, слияния с master/dev, повторной корректировки версий, борьбы с конфликтами слияния,


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


Эта статья посвящена Maven, но есть и много альтернатив Gradle.


Пример проекта можно найти на нашей странице GitHub.


Семантическое управление версиями и Git


Семантическое управление версиями это система классификации ваших выпусков. Я уверен, что вы видели такие номера версий, как 1.6.4, 1.7.10, 1.12.2 и другие. Эти цифры обозначают MAJOR.MINOR.PATCH (МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ)


Кроме того, существуют версии SNAPSHOT, которые выглядят одинаково, но с добавлением -SNAPSHOT в конце, например 1.14.4-SNAPSHOT.


Типичный процесс выпуска состоит из следующих шагов:


  1. Создайте release ветку из ветки разработки (здесь и далее ветка разработки development branch).


  2. Измените версию во всех файлах pom.xml с SNAPSHOT (1.2.3-SNAPSHOT) на non-SNAPSHOT (1.2.3) в release ветке.


  3. Увеличьте версию SNAPSHOT на ветке develop(1.2.4-SNAPSHOT).


  4. Когда все будет сделано для release, объедините release ветку с master веткой. Это актуальный релиз.


  5. Слейте master ветку или ветку release обратно в ветку разработки.



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


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


Каковы были мои цели?


Я хочу автоматизировать весь процесс, чтобы не беспокоиться об ошибках.


Текущее состояние master ветви никогда не должно содержать версию SNAPSHOT.


Я хочу подключить его к конвейерам CI, но с ручным запуском.


Я никогда не хочу иметь дело с merge конфликтами.


Я также хочу использовать его для hotfixes (которые происходят из master ветки).


Плагин gitflow-maven


Возможно, вы знаете плагин версий maven, который легко позволяет устанавливать версии внутри ваших файлов pom.xml. Однако для этого мне необходимо вручную ввести новую версию. Я хочу, чтобы мое решение автоматически выводило следующую версию на основе текущей версии.


К счастью, уже есть инструменты, помогающие достичь моих целей. Поскольку проблема довольно распространена, несколько человек пытались ее решить. Однако из всех найденных мною подключаемых модулей и инструментов поддерживается только один, при этом предоставляющий достаточно параметров конфигурации: gitflow-maven-plugin.


В нем есть именно то, что мне нужно:


Увеличение номеров версий.


Создание release ветки.


Создание ветки hotfix.


Объединение (Merging) веток.


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


Все это можно сделать, выполнив цели (goals) maven. Нам нужно только указать плагину, как себя вести и какое число увеличивать.


Некоторые примеры:


Следующие команды показывают несколько примеров, которые я использовал при оценке плагина.


$ mvn gitflow:release-start -B

Создает ветку release из ветки разработки без ввода данных пользователем (-B Batch Mode)


$ mvn gitflow:release

Создает релиз прямо из ветки разработки. Плагин объединяет текущее состояние разработки с master веткой и увеличивает номер версии в ветке разработки.


В этом примере нет флага пакетной обработки, что означает, что пользователю предлагается ввести всю недостающую информацию.


$ mvn gitflow:hotfix-start -B

$ mvn gitflow:hotfix-finish -B -DhotfixVersion=1.8.9b 

На первом этапе создает ветку hotfix из master ветки, затем выпускает исправление с версией исправления 1.8.9b на втором этапе. Все цели плагина могут быть выполнены в любой ветке. Из-за этого я должен указать плагину, какое исправление я хочу выпустить.


Конфигурация


Добавить зависимости плагина достаточно просто, просто добавьте следующее в плагины сборки poms:


<build>    <plugins>        <plugin>            <groupId>com.amashchenko.maven.plugin</groupId>            <artifactId>gitflow-maven-plugin</artifactId>            <version>1.13.0</version>            <configuration>                <!-- optional configuration -->            </configuration>        </plugin>    </plugins></build>

Последнюю версию можно найти на GitHub или в maven central.


Дополнительная настройка хорошо документирована на странице плагинов GitHub. Вот пример конфигурации с выделением некоторых параметров конфигурации:


<configuration>    <!-- We use maven wrapper in all our projects instead of a local maven installation -->    <mvnExecutable>./mvnw</mvnExecutable>    <!-- Dont push to the git remote. Very useful for testing locally -->    <pushRemote>true</pushRemote>    <!-- Set to true to immediately bump the development version when creating a release branch -->    <commitDevelopmentVersionAtStart>false</commitDevelopmentVersionAtStart>    <!-- Which digit to increas in major.minor.patch versioning, the values being 0.1.2 respectively.         By default the rightmost number is increased.         Pass in the number via parameter or profile to allow configuration,         since everything set in the file can't be overwritten via command line -->    <versionDigitToIncrement>${gitflowDigitToIncrement}</versionDigitToIncrement>    <!-- Execute mvn verify before release -->    <preReleaseGoals>verify</preReleaseGoals>    <preHotfixGoals>verify</preHotfixGoals>    <!-- Configure branches -->    <gitFlowConfig>        <productionBranch>master</productionBranch>        <!-- default is develop, but we use development -->        <developmentBranch>development</developmentBranch>    </gitFlowConfig></configuration>

Это отличный плагин, все работает безупречно, когда я запускаю его локально. Есть несколько избранных настроек, чтобы работать с Gitlab CI.


Автоматизация с помощью Gitlab CI


Мы запускаем конвейер CI/CD с использованием Gitlab CI для наших проектов, поэтому каждый новый commit в нашей ветке разработки приводит к созданию snapshot, а merge для master к release.


Как описано выше, моя цель автоматизировать разработку, master merge и связанные с этим обновления версий, а также hotfixes.


Я использую конвейеры Gitlab CI, чтобы упростить процесс и в то же время сделать его доступным для моих коллег. Вот пример:



Вот как выглядит конвейер ветвления разработки в моем примере с дополнительными этапами release. Поэтому, если я хочу создать release, я просто запускаю этап release, и он автоматически устанавливает версию без snapshot, объединяет (merge) ее с master и переводит версию в ветке разработки на следующую версию snapshot. Без каких-либо дополнительных действий с моей стороны.


Заставляем git работать в Gitlab CI


Если вы пробовали использовать команды git внутри Gitlab CI, то знаете: это не совсем просто, поскольку у исполнителей CI нет учетных данных git.


Для простоты я использую токены доступа с правами write_repository. Я назначил для этого специального пользователя, чтобы видеть, какие коммиты были созданы автоматически.


Я ввожу токен через переменную среды GITLAB_TOKEN, которую я установил как protected, и помечаю ветки development, release/* и hotfix/* как защищенные (protected). Таким образом, только сборки на тех ветках имеют доступ к токену.


Я вручную устанавливаю git remote на runner, чтобы среда CI могла отправлять данные в репозиторий. Я использую переменные, предоставленные Gitlab, поэтому мне не нужно ничего жестко кодировать:


$ git remote set-url --push origin "https://oauth2:${GITLAB_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git"

С помощью этого git команды могут выполняться с использованием учетных данных введенного токена доступа. Git также требует некоторой информации о пользователе, выполняющем действия git. Желательно, чтобы пользователь git соответствовал пользователю, чей токен доступа мы используем. В моем примере:


$ git config user.name "Gitlab CI"$ git config user.email gitlab-ci@viesure.io

Благодаря этому я могу легко найти все коммиты git, сделанные CI. Весь фрагмент кода доступен в репозитории примеров.


Собираем все вместе


Теперь, когда я могу получить доступ к git из CI, мне нужно настроить плагин gitflow. Я столкнулся с некоторыми особенностями.


Для простоты я использую предопределенные переменные, чтобы решить, какую цифру версии я хочу увеличить:


MINOR для релизов


PATCH для hotfixes


Можно также передать переменную при выполнении конвейера или получить ее другим способом.


Все цели (goals) передаются с параметром -B, который означает пакетный режим и означает, что пользовательский ввод не будет запрашиваться.


Автоматический Release


$ ./mvnw gitflow: release -B -DgitflowDigitToIncrement = $RELEASE_DIGIT

Полный процесс выпуска относительно прост. Плагин объединяет ветку разработки в master без SNAPSHOT внутри версии, а затем увеличивает версию для разработки. Я просто вызываю цель (goal ) maven и сообщаю ей, какую цифру увеличивать.


Ручная разблокировка


$ ./mvnw gitflow: release-start -B -DgitflowDigitToIncrement = $RELEASE_DIGIT

$ git push origin HEAD

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


$ git symbolic-ref refs/heads/$CI_COMMIT_REF_NAME refs/remotes/origin/$CI_COMMIT_REF_NAME$ ./mvnw gitflow:release-finish -B -DgitflowDigitToIncrement=$RELEASE_DIGIT

Завершение release приносит с собой первый обходной путь. Git хранит ссылку (сокращенно ref) на HEAD всех ваших веток. Однако Gitlab CI не устанавливает все эти ссылки при проверке репозитория. Плагин использует эти ссылки на HEAD для проверки веток. Тем не менее, у него есть правильные локальные ссылки, поэтому я просто создаю недостающую ссылку HEAD.


После этого цель окончательного выпуска объединяет ветвь выпуска в master ветку и ветку разработки, увеличивая версию для разработки.


Исправление (Hotfix)


Исправление следует тому же процессу, что и выпуск вручную, за исключением того, что оно запускается на мастере, а не на разработке.


$ ./mvnw gitflow:hotfix-start -B -DgitflowDigitToIncrement=$HOTFIX_DIGIT$ git push origin HEAD

Hotfix-start создает ветку hotfix, которая уже содержит увеличенную версию.


$ export CURRENT_VERSION=${CI_COMMIT_REF_NAME/hotfix\/}$ git symbolic-ref refs/heads/$CI_COMMIT_REF_NAME refs/remotes/origin/$CI_COMMIT_REF_NAME$ ./mvnw gitflow:hotfix-finish -B -DgitflowDigitToIncrement=$HOTFIX_DIGIT -DhotfixVersion=$CURRENT_VERSION

Hotfix-finish объединяет его в master ветку и ветку разработки. Однако для исправления требуется еще один параметр: версия исправления. Причина этого опять же в том, что плагин разработан для локального использования, где у вас может быть несколько веток. Он не ожидает выполнения цели внутри ветки исправления.


Как сказано выше, hotfix-start уже увеличивает номер версии, чтобы обозначить версию исправления. Таким образом, имя ветки уже указывает версию исправления.


Я просто извлекаю версию из имени текущей ветки. Поскольку задание конвейера исправления определено для ветвей исправления, оно будет выполняться только в указанной ветке.


Резюме


Это оно. Благодаря этому вы всего в одном клике от всех изменений версий и ветвлений, которые вам когда-либо понадобятся!


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


Мне больше никогда не придется думать о порядке, в котором мне нужно разветвлять и увеличивать версии. CI позаботится об этом за меня.


Вы можете найти полный сценарий Gitlab CI и пример проекта со всеми приведенными выше фрагментами кода в нашем репозитории GitHub.


Ссылки


Подробнее..

Перевод Автоматизация рабочего процесса Java-проекта с помощью модифицированной модели ветвления Gitflow

06.10.2020 10:05:04 | Автор: admin

Автоматизация рабочего процесса Java-проекта с помощью модифицированной модели ветвления Gitflow


Ключевые выводы


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


Документация по использованию Gitflow в размещения в источнике информации в лучшем случае является нечеткой.


Функции изолированы внутри ветвей. Вы можете управлять своими собственными изменениями функций изолированно. Этот подход отличается от разработки на основе магистралей, когда каждый разработчик фиксируется в основной ветке не реже одного раза в 24 часа.


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


Обновление от 13 февраля 2019 г.: первоначальное оформление этой статьи вызвало большой отклик, в основном положительный, а иногда и не очень. Основным предметом разногласий было использование нами термина непрерывная доставка в среде, где релиз выполняются вручную. Если вы работаете в команде, которая развертывает сотни релизов в день, наша структура может вам не подойти. Однако, если вы, как и мы, работаете в жестко регулируемой отрасли, такой как финансы, где релиз более контролируемы, и вы хотите максимально использовать возможности ветвления, автоматической интеграции, автоматического размещения и управления версиями, то это решение может работать для вас так же, как и для нас


Много лет назад я был на технологической конференции, где наткнулся на новомодную штуковину на выставке под названием Git. Я узнал, что это инструмент управления версиями нового поколения, и моя первая реакция была такой: Зачем нам это, у нас уже есть SVN? Это было тогда. Сегодня группы разработчиков массово переходят на Git, и вокруг промежуточного программного обеспечения и плагинов возникла огромная экосистема.


Gitflow это совместная модель ветвления, которая пытается использовать мощность, скорость и простоту ветвления Git. Как было написано ранее в InfoQ, этот подход действительно сопряжен со своим набором проблем, особенно в отношении непрерывной интеграции, но это была именно та проблема, которую мы стремились решить. Gitflow был представлен Винсентом Дриссеном в его блоге 2010 года Успешная модель ветвления Git. Gitflow упрощает совместную разработку, позволяя командам изолировать новую разработку от завершенной работы в отдельных ветвях, позволяя вам выбирать функции для релиза, при этом поощряя частые коммиты и автоматическое тестирование. Мы обнаружили, что это дает более чистый код, продвигая регулярные проверки кода во время слияния, даже проверки собственного кода, тем самым выявляя ошибки, возможности для рефакторинга и оптимизации.


Но когда дело доходит до внедрения Gitflow в автоматизированном конвейере развертывания, подробности становятся очень специфичными для вашей среды разработки, и появляются бесконечные возможности. Следовательно, документация является разреженной. Учитывая известные названия ветвей master, development, feature и т.д., какие ветви мы строим, какие тестируем, какие развертываем в нашей команде в виде Snapshot, какие развертывают выпуски и как автоматизируют развертывания в Dev, UAT, Prod и т.д.?


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


Описанный здесь проект использует Java и Maven, но мы считаем, что любая среда может быть адаптирована аналогичным образом. Мы используем GitLab CI с настраиваемыми сценариями запуска, но также можно использовать Jenkins или плагин GitHub CI; мы используем Jira для отслеживания проблем, IntelliJ IDEA в качестве нашей IDE, Nexus в качестве репозитория зависимостей, и мы используем Ansible для нашего автоматического развертывания, но их можно заменить любые аналогичные инструменты.


Эволюция


В допотопные времена разработчики тратили недели или месяцы на создание функции приложения, откуда они передавали завершенную работу интегратору благонамеренному и преданному человечеству парню, который брал все такие функции, интегрировал их., разрешал конфликты и подготавливал к релизу. Процесс интеграции был пугающим, чреватым ошибками, непредсказуемым по графику и последствиям, породив заслуженное название интеграционный ад. Затем на рубеже веков Кент Бек выпустил свою книгу Объяснение экстремального программирования, в которой отстаивал концепцию непрерывной интеграции; практика, когда каждый разработчик создает и интегрирует код в основную ветвь и запускает тесты в автоматическом режиме каждые несколько часов каждый день. Вскоре после этого появился Круиз-Контроль Мартина Фаулера Thoughtworks с открытым исходным кодом, один из первых в истории инструментов автоматизации CI.


Вход в Gitflow


Gitflow рекомендует использовать feature ветки для разработки отдельных функций и отдельные ветки для интеграции и релиза. Следующий рисунок, перепечатанный из блога Винсента Дриссена, теперь хорошо знаком командам разработчиков Git.



Как пользователи Git, все мы знакомы с веткой под названием master; это основная ветка или trunk, создаваемая Git по умолчанию при первой инициализации любого проекта Git. Прежде чем принять Gitflow, вы, скорее всего, делали коммит в своей основной ветке.


Запуск Gitflow


Чтобы запустить проект с помощью Gitflow, существует однократный шаг инициализации, на котором вы создаете ответвление от master под названием develop. С этого момента develop становится всеобъемлющей ветвью, где весь ваш код размещается и тестируется, по сути, становясь вашей основной ветвью интеграции.



Как разработчик, вы никогда не будете делать коммит непосредственно в ветке develop, и вы никогда не будете делать коммит непосредственно в ветке master. Master стабильная ветка, которая содержит только те работы, которые готовы к производству, либо выпущены, либо готовы к релизу. Если что-то находится в мастере, то это прошлый или будущий производственный релиз.


Бранч develop именуется "нестабильной". Возможно, это название немного ошибочно он стабилен тем, что содержит код, предназначенный для выпуска; и он должен быть скомпилирован и испытания должны пройти. Он называется так только потому, что он содержит работу, которая может быть или не быть завершенной, и, следовательно, "нестабильной".


Итак, где мы работаем? Вот где начинает материализоваться остальная часть картины:


Вы получаете новую задачу от Jira, над которой нужно работать. Сразу же вы разветвляете функциональную ветку, обычно от разработки, если она находится в стабильной точке, или от master:



Мы договорились о том, что наши функциональные ветки называются feat-, за которыми следует номер проблемы Jira. (Если существует более одной проблемы Jira, просто используйте задачу Epic или Parent либо один из основных номеров задач, за которым следует очень краткое описание функции.) Например, feat-SDLC-123-add-name-field. Префикс feat- обеспечивает шаблон, который CI-сервер может использовать, чтобы идентифицировать это как ветвь функции. Скоро мы увидим, почему это важно. В этом примере SDLC-123 это номер нашей проблемы Jira, который дает нам визуальную ссылку на основную проблему, а оставшееся описание дает нам краткое описание этой функции.


Теперь разработка идет параллельно: все работают над своими функциональными ветками одновременно, некоторые команды работают над одной и той же ветвью, выполняя эту функцию, другие работают над разными функциями. Мы обнаружили, что за счет частого слияния с ветвью разработки команда сократила время, затрачиваемое на ад слияния (merge hell).


Релизы, Snapshots и общие репозитории


Давайте проясним это несколькими словами. На большинстве предприятий есть репозиторий с одной зависимостью, например Sonatype Nexus. Это репо содержит два вида двоичных файлов. Бинарные файлы SNAPSHOT обычно именуются с использованием версии semver (разделенных точками из трех частей), за которыми следует слово -SNAPSHOT (например, 1.2.0-SNAPSHOT). Версии исполняемых файлов релиза имеют одно и то же имя, кроме суффикса -SNAPSHOT (например, 1.2.0). Сборки моментальных Snapshot уникальны тем, что каждый раз, когда вы создаете двоичный файл с этой версией Snapshot, он заменяет любой предыдущий двоичный файл с таким же именем. Сборки релизов не такие; как только вы создадите сборку релиза, вы можете сообщить, что двоичный файл, связанный с этой версией, никогда не будет изменен в Nexus.


Теперь представьте, что вы работаете над функцией X, а ваша партнерская команда работает над функцией Y. Вы оба одновременно ответили на разработку, так что у вас обоих одна и та же базовая версия в вашем POM (скажем, 1.2.0-SNAPSHOT). Теперь предположим, что вы запустили свою сборку и развернули ветку функций в Nexus, а вскоре после этого ваша компаньонская команда запустила свою сборку и развернула ее в Nexus. В таком сценарии вы никогда не узнаете, какой двоичный файл функции был в Nexus, поскольку 1.2.0-SNAPSHOT будет относиться к двум различным двоичным файлам, соответствующим двум отдельным ветвям функций (или более, если таких ветвей функций больше!) Это очень часто возникающий конфликт.


GitLab CI


Тем не менее, мы поручаем командам совершать коммиты чаще и быстрее! Итак, как нам избежать таких конфликтов? Необходимо указать GitLab CI, чтобы он построил ошибку, но не развертывал ее в Nexus, связав ветки feat- с этапом жизненного цикла проверки Maven (который создается локально и запускает все тесты), а не этапом развертывания Maven (который будет отправлять двоичный Snapshot в Nexus).


GitLab CI настраивается путем определения файла (с именем .gitlab-ci.yml) в корне проекта, который содержит точные шаги выполнения CI / CD. Прелесть этой функции в том, что сценарий запуска затем связывается с вашим коммитом, поэтому вы можете изменять его в зависимости от комитта или ветки.


Мы настроили GitLab CI со следующим заданием, содержащим регулярное выражение и скрипт для создания веток функций:


feature-build:  stage:     build  script:    - mvn clean verify sonar:sonar  only:    - /^feat-\w+$/

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


Разработка, управляемая покрытием


Сейчас самое время обсудить тестовое покрытие. Идея IntelliJ имеет режим выполнения покрытия, который позволяет вам запускать тестовый код с покрытием (либо в режиме отладки, либо в режиме выполнения) и закрашивает поля в зеленый или розовый цвет, в зависимости от того, был ли этот код покрыт или нет. Вы также можете (и должны) добавить в Maven плагин покрытия (например, Jacoco), чтобы вы могли получать отчеты о покрытии как часть вашей сборки интеграции. Если вы используете среду IDE, которая не окрашивает поля, вы можете использовать эти отчеты, чтобы найти участки непокрытого кода.



[Одно замечание по этому поводу к сожалению, все еще есть много профессиональных команд разработчиков, которые, хотя и проповедуют непреодолимую ортодоксальность автоматизации и разработки, тем не менее по тем или иным причинам упускают возможность расширить охват тестированием. Теперь мы не будем теми, кто скажет таким командам вернуться и добавить тесты к каждому открытому фрагменту кода; но, как хорошие граждане-разработчики, мы считаем своим долгом ввести тесты хотя бы для кода, который мы добавили или изменили. Сопоставляя поля с цветовым кодом покрытия и введенный нами код, мы можем быстро определить возможности для введения новых тестов.]


Тесты выполняются как часть сборки Maven. На этапе тестирования Maven выполняются модульные тесты (обозначенные именем, которое начинается с Test-something.java или заканчивается Test.java, Tests.java или TestCase.java). Maven verifyphase (требуется плагин Maven Failsafe) также выполняет интеграционные тесты. Вызов mvn verify запускает сборку, за которой следует конвейер этапов жизненного цикла, включая тестирование и проверку. Мы также рекомендуем установить SonarQube и плагин Maven SonarQube для статического анализа кода на этапе тестирования. В нашей модели каждый коммит или слияние ветки выполняет все эти тесты.


Интеграция нашей работы


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


У нас также есть политика, которую мы применяем внутри GitLab, которую мы не можем объединить в разработку без проверки кода в форме запроса на слияние:




В зависимости от вашей политики SDLC вы можете заставить разработчиков провести проверку кода с кем-то еще, снабдив свои слияния списком утверждающих. Или вы можете применить более расслабленную стратегию, разрешив разработчикам выполнять свои собственные проверки кода после просмотра своего собственного запроса на слияние. Эта стратегия прекрасно работает, поскольку побуждает разработчиков хотя бы пересматривать свой собственный код, но, как и любая система, она сопряжена с очевидными рисками. Обратите внимание, что, поскольку двоичный файл никогда не будет развернут на Nexus или иным образом предоставлен, версия POM, содержащаяся в ветке разработки, не имеет значения. Вы можете назвать его 0.0.0-SNAPSHOT или просто оставить исходную версию POM, откуда она была разветвлена.


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


На этом этапе мы разветвляем ветвь релиза от develop. Но в небольшом отступлении от традиционного Gitflow мы не называем это релизом; мы называем ветвь по номеру версии релиза. В нашем случае мы используем семантическое управление версиями из трех частей, поэтому, если это основной релиз (новые функции или критические изменения), мы увеличиваем основной (первый) номер, второстепенный релиз мы увеличиваем второстепенный (второй) номер, а если патч, то третий. Таким образом, если предыдущий релиз был 1.2.0, следующий релиз может быть 1.2.1, а версия моментального Snapshot pom будет 1.2.1-SNAPSHOT. Таким образом, наша ветка будет называться соответственно 1.2.1.


Настройка конвейера


Мы настроили наш конвейер GitLab CI так, чтобы он распознавал создание ветки релиза (ветка релиза идентифицируется по semver номеру, разделенному точкой из трех частей; на языке регулярных выражений: \d+\.\d+\.\d+). Средство выполнения CI/CD сконфигурировано для извлечения имени релиза из имени ветки и для использования плагина версии для изменения версии POM, чтобы включить SNAPSHOT, соответствующий этому имени ветки (1.2.1-SNAPSHOT в нашем примере).


release-build:  stage:    build  script:     - mvn versions:set -DnewVersion=${CI_COMMIT_REF_NAME}-SNAPSHOT    # now commit the version to the release branch    - git add .    - git commit -m "create snapshot [ci skip]"    - git push    # Deploy the binary to Nexus:    - mvn deploy  only:    - /^\d+\.\d+\.\d+$/  except:    - tags

Обратите внимание на [ci skip] в коммит сообщении. Это очень важно для предотвращения зацикливания, когда каждый коммит запускает новый запуск и новый коммит!


После того, как исполнитель CI вносит изменения в POM, он фиксирует и отправляет обновленный файл pom.xml (теперь содержащий версию, которая соответствует имени ветки). Теперь POM удаленной ветви релиза содержит правильную версию SNAPSHOT для этой ветви.


GitLab CI, все еще идентифицирующий эту ветвь релиза по семантическому шаблону управления версиями (/^\d+\.\d+\.\d+$/, например 1.2.1) своего имени, распознает, что в ветке произошло событие push. Средство выполнения GitLab выполняет mvn deploy для создания сборки SNAPSHOT и развертывания в Nexus. Теперь Ansible развертывает его на сервере разработки, где он доступен для тестирования. Этот шаг выполняется для всех нажатий на ветку релиза. Таким образом, небольшие изменения, которые разработчики вносят в релиз-кандидат, запускают сборку SNAPSHOT, релиз SNAPSHOT для Nexus и развертывание этого артефакта SNAPSHOT на серверах разработки.


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


И, наконец, мы объединяемся в master, заставляя Git пометить релиз номером версии semver из имени исходной ветки релиза, развернуть весь пакет на Nexus и запустить тесты сонара.


Обратите внимание, что в GitLab CI все, что вам нужно для следующего шага работы, нужно обозначить как артефакты. В этом случае мы собираемся развернуть наш артефакт jar с помощью Ansible, поэтому мы обозначили его как артефакт GitLab CI.


master-branch-build:  stage:    build  script:    # Remove the -SNAPSHOT from the POM version    - mvn versions:set -DremoveSnapshot    # use the Maven help plugin to determine the version. Note the grep -v at the end, to prune out unwanted log lines.    - export FINAL_VERSION=$(mvn --non-recursive help:evaluate -Dexpression=project.version | grep -v '\[.*')    # Stage and commit the binaries (again using [ci skip] in the comment to avoid cycles)    - git add .    - git commit -m "Create release version [ci skip]"    # Tag the release    - git tag -a ${FINAL_VERSION} -m "Create release version"    - git push     - mvn sonar:sonar deploy  artifacts:    paths:    # list our binaries here for Ansible deployment in the master-branch-deploy stage    - target/my-binaries-*.jar  only:    - mastermaster-branch-deploy:  stage:    deploy  dependencies:    - master-branch-build  script:   # "We would deploy artifacts (target/my-binaries-*.jar) here, using ansible  only:    - master

Устранение ошибок


Во время тестирования могут быть обнаружены исправления ошибок. Они исправляются прямо в ветке релиза, а затем снова объединяются для разработки. (Develop всегда содержит все, что было или будет выпущено.)



Наконец, ветвь релиза утверждается, и она объединяется с главной. Master имеет принудительную политику GitLab, чтобы никогда не принимать слияния, кроме как из ветки релиза. Бегун GitLab проверяет объединенный код в master, у которого все еще есть версия SNAPSHOT ветки релиза. Средство выполнения GitLab снова использует плагин версий Maven для выполнения версий: установите цель с помощью набора параметров removeSnapshot. Эта цель удалит -SNAPSHOT из версии POM, и runner GitLab отправит это изменение на удаленный master, пометит релиз, увеличит версию POM до следующей версии SNAPSHOT и развернет ее на Nexus. Это развернуто в UAT для тестирования QA и UAT. Как только артефакт будет одобрен для релиза в производство, группы производственного обслуживания возьмут артефакт релиза и развернут его в производственной среде. (Этот шаг также можно автоматизировать с помощью Ansible, в зависимости от вашей корпоративной политики.)



Патчи и hotfix


Мы должны упомянуть еще об одном побочном рабочем процессе, и это касается патчей или хотфиксов. Они запускаются, когда проблема обнаруживается в производственной среде или во время тестирования артефакта релиза, например, ошибка или проблема с производительностью. Hotfix аналогичны веткам релиза. Они названы по названию релиза, как и ветка релиза. Единственная разница в том, что они разветвлены не от разработки, а от masterа.



Проделана работа по завершению хотфикса. Как и ветка релиза, hotfix запускает развертывание Nexus SNAPSHOT и развертывание в UAT. Как только это сертифицировано, оно снова объединяется с разработкой, а затем сливается с masterом для подготовки к релизу. Master запустит сборку релиза и развернет двоичный файл релиза на Nexus.


Заключение


Мы можем суммировать все это в следующей схеме:



Итак, у нас есть Gitflow. Мы призываем команды разработчиков любого размера изучить и опробовать эту стратегию. Мы считаем, что он имеет следующие достоинства:


Feature изолированы. Легко управлять своими собственными изменениями Feature изолированно, с обычным предупреждением о ветвлении Feature, которое может затруднить интеграцию команды в очень активную Feature, или коммиты не часто объединяются


Разделение Feature, которое позволяет вам выбрать, какие Feature включить в релиз. Альтернативный подход к этому постоянно релизить код, связанный с Feature, которые скрыты за флагами Feature.


Процесс интеграции и слияния привел к тому, что наша команда провела более дисциплинированную проверку кода, что помогло продвинуть чистое кодирование.


Автоматическое тестирование, развертывание и релиз для всех сред, которые соответствуют требованиям наших команд и предпочтительному способу работы.


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


Нам интересно узнать о вашем опыте работы с Gitflow и конвейерами развертывания, поэтому, пожалуйста, оставляйте свои комментарии ниже.


Дополнительная информация


Для более традиционной обработки Gitflow с использованием Atlassian Bamboo и BitBucket см. Здесь.


Существует также отличный плагин Gitflow Maven, который активно поддерживается Алексом Мащенко, который работает так же, как плагин релиза Maven на Gitflow. Это может быть адаптировано к нашей предлагаемой реализации Gitflow.


Об авторах


Виктор Граци работает в Nomura Securities над разработкой приложений для корпоративной инфраструктуры. Победитель Oracle Java, Виктор также работал ведущим редактором очереди Java в InfoQ и был членом комитета по выполнению процессов сообщества Java.


Брайан Гарднер недавний релизник Технологического института Стивенса, где он получил степень бакалавра и магистра в области компьютерных наук. В настоящее время Брайан работает в Nomura инженером-программистом в группе разработки инфраструктуры. В основном он проводит свой день, работая над серверными службами Spring Boot или над конвейерами больших данных с помощью Apache Spark.

Подробнее..

Поддерживаем разработку нескольких версий продукта в Git. Станислав Лукьянов (GridGain)

28.10.2020 10:05:26 | Автор: admin


Всем привет! Меня зовут Станислав Лукьянов. Я работаю в компании GridGain. Сегодня я хотел поговорить о том, как мы поддерживаем старые версии в Git.



Сначала пара слов о том, что это будет за доклад, кому будет полезен и кто я такой.



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


Эта тема будет полезна:


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

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



Продукт GridGain это распределенная СУБД и платформа для обработки данных. Она основана на продукте, который называется Apache Ignite, который open source. Все, что есть в Ignite, на слайде выделено красным. И GridGain добавляет вокруг какое-то количество интерпрайзных фич, которые тут по бокам.


И плюс к этому занимается платной поддержкой и выпуском платных патчей для Ignite, чем и зарабатывает.



Кто этим пользуется? Пользуются этим вот эти ребята. Тут много всяких компаний. В основном это финтех, банки и те, кто их обслуживают.


И все, что их объединяет, это то, что это все жесткий и кровавый enterprise. В чем проблема с enterprise?



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



Он хочет обновляться как можно реже и затягивать как можно меньше патчей.



Из-за этого нам приходится поддерживать много старых версий. Много это сколько?


Вот такая у нас release model:



Тут я вывел версии, которые мы выпустили в наших активных ветках за последний год. Мы выпускаем minor-версии примерно раз в квартал. Поддерживаем их два года. Это означает, что мы поддерживаем порядка 8 minor-веток одновременно. В них мы выпускаем патчи. В среднем они выпускаются по одному в месяц на каждую minor-версию.


Если посмотреть на слайд, то получится, что у нас 5-10 версий выходят ежемесячно. Это довольно много.



В чем же проблема? В чем сложность, чтобы поддерживать все старые ветки?


Давайте пойдем наивно и попробуем сделать все нормально.



Есть у нас мастер, мы в него коммитим.



В какой-то момент захотели выпустить версию.



Повесили тэг на коммит, отдали в QA. QA прошел, не нашел никаких проблем. Версию выпустили.



Выпустили так еще одну.



И стали готовиться к следующей.



Пока версия была в QA, произошло следующее.



Сначала мы запилили еще что-то, т. е. какой-то фикс или фичу, которая попала нам в мастер, но которую мы не хотим в версии 1.3. А потом QA нашел в 1.3 какой-то баг, который мы тоже пофиксили.



Вопрос: Как теперь протащить B в 1.3?.


Самое очевидное решение это переставить тэг 1.3.



Кто видит в этом проблему? Естественно, все понимают, что такое scope creep. Мы переставили тэг. И у нас в 1.3 еще попал коммит А. Очевидно, что решение плохое.


Что мы еще можем сделать?



Можем заревертать А. Переставить после этого 1.3. И после выпуска 1.3 А закоммитить обратно в мастер. Но очень много для этого нужно делать телодвижений. Можно было вообще сказать, что надо было мастер зафризить, пока мы 1.3 не выпустим, но слишком много помех для текущей разработки.



Естественно, все знают в 2019-ом году, что мы хотим сделать branch под 1.3 и в отдельном branch проводить стабилизацию, т. е. там зафиксить B.


В той картине, как она выглядит сейчас, кто-то видит еще проблему? А она есть, потому что так, как мы это сделали сейчас, мы забыли дотащить B до мастера.



И как это сделать просто, и как дотащить B и туда, и туда, может быть, неочевидно.


Немножко усложним пример.



Скажем, что мы стали делать branches для каждой ветки, но вспомним, что релизы живут независимо. Выпустили первую версию 1.3.0. Прогнали через тестирование, выпустили.



Выпустили следующую, отбранчевались от нулевой.



Потом приготовились выпускать вторую.



И снова та же ситуация.



Есть коммит А, который мы не хотим в 1.3.2. Но скажем, что мы хотим его когда-нибудь протащить в ветку 1.3, но не сейчас, т. е. не в 1.3.2.


Очевидное решение это сразу сделать ветку 1.3.3. И туда все протащим, и все будет хорошо.



После этого мы снова находим какую-то проблему в 1.3.2, которая нам там нужна.



И теперь нам нужно ее протащить и в 1.3.2, и в 1.3.3.



И проблема здесь в том, что разработчик принимает очень много решений на основе того, что он знает о версиях, которые выпускаются. Он должен знать, что есть 1.3.2. Эта версия в QA и в нее надо тащить не все подряд. Есть 1.3.3., в которую надо тащить все подряд, что должно оказаться в ветке 1.3. Это довольно много информации.


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



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



Сформулируем проблемы, на которые мы посмотрели:


  • У нас есть релизы в разных состояниях: какие-то мы еще не начали, какие-то мы уже выпустили, а какие-то мы наполовину зафризили, они сейчас в стадии стабилизации и все подряд мы туда тащить не хотим.
  • У нас есть риск того, что, если мы что-то пофиксили в одной ветке, мы это не пофиксим в другой. И нужно этот риск как-то минимизировать.
  • Чем больше версий вы поддерживаете, тем больше веток у вас одновременно живет, а значит, что проблемы тоже множатся.


Из этого формулируем свои требования:


  1. Одновременные релизы не должны мешать друг другу и не должны мешать текущей разработке. Если нам надо закоммитить, то мы должны иметь возможность что-то закоммитить. Если нам надо выпускать релиз, вне зависимости оттого, что там еще мы выпускаем, мы имеем возможность забросить релиз в QA на стабилизацию.
  2. Мы недолжны терять консистентности между релизами. Если в старых релизах мы что-то пофиксили, то во всех новых это тоже должно быть пофиксено, потому что пользователь не должен видеть багов, которые для него уже один раз пофиксили.
  3. И все это должно масштабироваться:

  • В ширину на большое количество версий, которые мы захотим поддерживать 2-3-4 года.
  • В глубину часто мы хотим выпускать патчи для патчей. Мы выпускаем версии с тремя-четырьмя-пятью цифрами. У нас есть ветки, которые живут какое-то время, в которых у нас по пять цифр. И это бывает нужно.


Как построим разговор дальше?


  • Начнем с существующих подходов к работе с Git. Рассмотрим парочку популярных и посмотрим, как они работают с версиями.
  • Потом посмотрим на то, как мы строили собственный подход, какие есть развилки.
  • И расскажу о паре проблем, которые мы все еще решаем.


Начнем с Github Flow.



Кто знает, что такое Github Flow? Кто не знает, вы на самом деле знаете, просто не понимали, что пользовались Github Flow.


Это самый простой подход к работе к Git, который может быть.



У вас есть мастер. Когда вы хотите что-то пофиксить, вы делаете feature branch, либо bugfix branch.



Когда закончили, то через pull request при integration testing review вмерживаете все в мастер.



Требования, которые выделяет Github Flow это: мастер должен быть постоянно стабилен и готов к deploy. Если у вас современный CI/CD, то, скорее всего, на каждый коммит в мастер, на каждый merge либо вы делаете deploy в production, либо принципиально можете сделать deploy в production, т. е. никакой стабилизации нет.



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



Как Github Flow справляется с требованиями, про которые мы говорили?


  • Релизы не мешают изменениям, потому что процесс выпуска релиза это всего лишь процесс merge. Нет никакой стабилизации. И нельзя сказать, что у нас одновременно с релизом что-то происходит, потому что выпуск релиза это merge в мастер, это мгновенный процесс.
  • Консистентность сохраняется, потому что есть всего одна ветка. И мы не можем забыть что-то куда-то промержить.
  • Очевидно, что это не масштабируется, потому что у нас всего лишь одна ветка.

Github Flow нам про версии вообще ничего не говорит и каких-то инструментов, чтобы поддерживать старые версии нам не дает.


Понятно, что это основной способ, как мы все работаем с Git. Фиксы в feature branch и merge в мастер с этого будем начинать. А снаружи будем накручивать все, что связано с выпуском версий.



Git Flow еще один очень популярный процесс. Он поддерживает две главных ветки, помимо мастера есть еще ветка develop.


Мастер это также постоянно стабильная штука, которую можно с любого места деплоить.


Develop это нестабильная ветка, в которой аккумулируются изменения.


Feature branches создаются из develop.



Потом вмерживаются в него обратно.



Когда мы готовимся сделать релиз, мы делаем release branch, в нем проводим стабилизацию.



Когда стабилизация релиза закончилась, мы вмерживаем его в мастер и обратно в develop, т. е. делаем сразу два merge.



Когда мы вмерживаем его в мастер, это считается моментом выпуска релиза.


Кроме обычных релизов, есть еще понятие hotfix релизов.



Отличие от обычных в том, что branch делается не от develop, а от головы мастера. Делаем такой hotfix, а также делаем там стабилизацию. И после этого также вмерживаем в мастер и в develop.



Вот и весь процесс.



Как он справляется с нашими требованиями?


  1. Релизы не мешают изменениям, потому что мы используем release branches. Мы этому научились в самом начале.
  2. Сохраняется ли консистентность между ветками, которые мы поддерживаем? И да, и нет.

  • С одной стороны, мы вмерживаем релизные branches, hotfix branches обратно в develop и в мастер. И это хорошо. Это значит, что их изменения мы не потеряем, по крайней мере, в develop.
  • Но если у вас есть несколько одновременно живущих release branches или вы одновременно готовите hot fix и релиз, то процесс не дает какого-то инструмента, как вам их синхронизировать. Скажем, у вас есть hot fix, который вы готовите с каким-то критическим патчем и какой-то релиз. Hot fix по этому процессу в релиз вмержен не будет. Вам нужно что-то уже накручивать поверх Git Flow для того, чтобы этот коммит не потерять.

  1. А как поддерживать большое количество версий Git Flow нам ничего не говорит. Он предполагает, что мы поддерживаем один hot fix, один релиз и желательно не одновременно.


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



Я дальше буду использовать сквозной пример. У нас есть мастер и 5 версий, которые мы поддерживаем.


К нам пришел кастомер и сказал, что у него есть проблема в версии 1.3. В нее нам нужно что-то закоммитить.


Разберемся, как мы это будем делать. Какие у нас есть развилки?



Во-первых, мы договорились, что мы хотим избегать регрессий. В нашем примере это значит, что, если мы хотим сделать вот так и закоммитить что-то в 1.3.



То мы на самом деле хотим это закоммитить вот так сразу в мастер, в 1.5, в 1.4, 1.3.


В каком порядке будем делать эти коммиты? Здравый смысл подсказывает, что просто закоммитить их в случайном порядке это плохая идея, а опыт подсказывает, что закоммитить все одновременно это невозможно. У вас могут быть merge-конфликты, вам может быть понадобиться что-то переделать для старых или для новых версий, поэтому мы не можем сказать, что мы просто возьмем и сразу сделаем все и везде.


Тогда у нас остаются два логичных подхода: master-first и target-first.



Master-first или upstream first начинаем с мастера, а потом по очереди промерживаем во все предыдущие ветки.


Ветки не пропускаем. Если хотим промержить в 1.3, то обязаны это сделать сначала в 1.4, а, чтобы сделать в 1.4, надо сделать в 1.5 и т. д.


Какие плюсы?


  • У нас нет моментов, когда мы нарушаем консистентность между релизами. Если у нас фикс есть в более старой ветке, значит мы до этого его уже сделали в более новой ветке. Такой ситуации, когда мы выпустили релиз кастомеру, отдали ему bugfix, а потом отдали ему какой-то релиз из более новой ветки и он этого bugfix не увидел, не будет с этим подходом.


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



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



Другой противоположный подход target-first.


Начинаем с фикса в 1.3 и поднимаемся вверх. И если нам вдруг надо, спускаемся вниз.


Плюс в том, что быстрый фикс в целевой версии. Мы можем пофиксить там и сразу зарелизить, а потом уже разбираться со всеми остальными.


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


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


Вот это небольшое сравнение:



Понятно, что в чем хорошо один, в том плох другой. Они антиподы друг для друга.


Мы для себя выбрали master-first, потому что консистентность превыше всего. И мы готовы за нее заплатить иногда более долгим фиксом в той версии, где этот фикс нам нужен прямо сейчас.



Тот пример, который у нас уже был ранее, когда у нас есть какая-то версия 1.3.2, которая уже в QA и нам нужно было протащить фикс А в ветку 1.3, но 1.3.2 уже был в QA, поэтому мы создали dev-ветку 1.3.3 для того, чтобы аккумулировать изменения там.


И после этого у нас два активных релиза в одной и той же ветке: 1.3.2 и 1.3.3.


Вопрос: Как разработчик принимает решение, что ему надо тащить?. Если он знает, что коммит нужен в какой-то версии в рамках ветки 1.3, то как он принимает решение, в какие именно релизы коммит протащить? Это достаточно сложно.



Решение, которое мы для себя придумали, это релиз мастер branches.


Первым для ветки 1.3 создается branch, который называется 1.3-master. Он играет для 1.3 такую же функцию, как мастер играет для всего проекта. Т. е. аккумулирует вообще все-все изменения.


В тот момент, когда нам нужно зарелизить что-то, мы делаем ветку от этого branch, от 1.3-master. Поэтому разработчик может видеть только мастер, протаскивать фиксы только туда. В нужный момент release engineers сделают ветку от этого 1.3-master. Ветки релизов в состоянии development, когда они еще не переданы в QA, нам в этом случае не нужны, потому что изменения могут накапливаться в 1.3-master.


А если нам нужно принести какой-то фикс во время QA, например, как здесь нам нужно было перенести фикс B в 1.3.2, то это делает release engineer, а не разработчик. Release engineer знает о scope релиза, за который он отвечает. У него есть доступ к этой ветке, он может сделать этот cherry-pick.



Следующая минорная, но все же развилка это как нам отмечать версии? Что я имею в виду?



Есть вариант, когда мы на каждую версию создаем по branch. Нужны ли нам там стабилизационные коммиты, находит ли QA проблемы или не находит все равно создаем по branch.



Часто предлагают вместо branches стараться использовать тэги, как это делает, например, Github Flow, когда мы просто на мастере ставим тэги. И только, если нам потребовалась стабилизация для какой-то версии, тогда мы уже делаем для нее branch.



Тут просто:


  • Тэги более легковесные, они не засоряют список branches. Он действительно потихоньку распухает.


  • Branches более универсальные, потому что, если заранее вы не знаете потребуется ли вам стабилизация или нет, то если потребуется, то вам придется тэг заменить на branch или как-то использовать их вместе. И это довольно трудоемко. Поэтому мы просто стали использовать branches. Тэги мы практически не используем в нашем процессе.




Последний момент о развилках. Как мы в мастер коммиты доносим? Мы уже поговорили обо всем, что мы делаем со старыми ветками, но как нам пофиксить мастер?


В чем тут сложность?



В мастер мы, наверное, хотим использовать стандартный процесс, практически Github Flow за тем исключением, что мы не требуем полной стабильности мастера.


Сделали bugfix-ветку, сделали там несколько коммитов. Вмержили в мастер.


Как нам после этого дотянуть несколько коммитов до предыдущих версий?



Первый вариант это прямой cherry-pick. Если, кто не знает, cherry-pick это команда, которая перетаскивает коммиты с одной ветки Git на другую.


Напрямую перетаскиваем все коммиты из bugfix release в старой ветке.


Какие здесь проблемы?


  • У нас могут быть какие-то изменения непосредственно в merge-коммите, которые были частью merge в мастер.


  • Во-вторых, мы таскаем целую кучу коммитов между ветками. Многие из них это всевозможные work-in-progress, которые часто могут быть мусорными штуками.


  • В-третьих, у нас получается некоторая разница между тем, как фикс выглядит в мастере и в старых ветках, потому что в мастере это отдельная ветка и merge-коммит, в старых ветках это просто несколько фиксов прямо в релизных мастерах. И это тоже некоторая проблема, их потом сложнее сопоставлять друг с другом.




Другой вариант cherry-pick -m. Что делает cherry-pick -m? В отличие от обычного cherry-pick он все коммиты схлопывает вместе. Вы натравливаете его на merge-коммит в мастере, говорите, что хотите взять коммиты из ветки bugfix. Он их все схлопывает вместе с изменениями, которые, возможно, происходили при merge. И таким образом вы перетаскиваете изменения в старые ветки.


В чем тут проблема? У нас все еще есть некоторая разница между тем, что у нас лежит в мастере и тем, что у нас лежит в старых версиях. И эта разница достаточно большая. В старых версиях у нас один атомарный коммит, а в мастере у нас их целая куча, да еще и с merge.


И этим достаточно сложно управлять, сложно сопоставлять изменения в мастере и в предыдущих релизах.



Тот путь, который мы выбрали для себя это merge --squash. Что делает merge --squash? Он вместо того, чтобы создавать merge-коммит в мастере, он создает squash-коммит, который примерно, как в cherry-pick -m, схлопывает все коммиты A, B, C из bugfix вместе и кладет их прямо в мастер. В мастере при этом никакого merge-коммита нет. Т. е. в мастере у нас лежит один коммит, соответствующий всему изменению, и мы его легко простым cherry-pickом одного коммита перетаскиваем на предыдущие ветки.


Это максимально удобная штука, если вам нужно часто делать cherry-pick bugfixes и фичей между ветками. И даже если это относится не к поддержке старых версий, а каким-то другим вашим процессам, то merge --squash спасает.



Поговорили обо всех частях процесса по отдельности, теперь посмотрим на то, как весь процесс выглядит вместе.


Сначала о том, как процесс видит разработчик и как мы вносим изменения в продукт, надевая шапку разработчика.



Мы можем не думать о release branches вообще, о конкретных релизах, мы можем думать только о мастер-branches, остальные мы вообще не видим.


И строго говоря, мы по процессу вообще запрещаем для всех, кроме release engineer, коммиты в релизной ветке.


Вот такую картину видят для себя разработчик:



Когда нужно сделать какой-то bugfix, он готовит себе bugfix-ветку. После интеграционного тестирования review и всего остального, вмерживает это все в мастер.



Потом делает cherry-pick по очереди в 1.5,



в 1.4,



в 1.3.



Вот и все. Это все, что нужно сделать разработчику. Процесс прямолинейный. Ни за какими предыдущими релизами следить не нужно.


Откуда разработчик получает информацию о том, в какие из этих веток коммитить. В какой минорной версии нам нужен этот фикс это обозначается прямо в Jira в fix version. И либо это делает тот, кто заводил тикет, либо это делает разработчик сам, исходя из своих знаний, какие фичи и в каких минорных релизах были добавлены. Если фиксят фичу, которая добавлена в 1.3, значит нужно промержить фикс вплоть до 1.3.


Как процесс видят те, кто занимаются выпуском релиза, как его видят release engineers?



Есть мастер, есть релизный master-1.3, от которого мы собираемся сделать релиз.



Когда мы готовимся релиз выпустить, то сначала весь его scope собирается в ветке 1.3-master.


После этого, когда весь scope готов, мы делаем релизную ветку 1.3.2.



Так мы только что ее сделали, мы знаем, что все, что лежит в 1.3-master в этот релиз у нас попало.


Пока релиз тестируется, мастер и 1.3-master продолжают развиваться независимо.



Если нам нужна какая-то стабилизация в 1.3.2, например, мы нашли какой-то баг B, то мы проводим его по обычному процессу.



Разработчики пофиксят его в мастере, потом в 1.3-master.



И потом release engineer протащит его в 1.3.2.




Еще раз посмотрим на те требования, которые мы выдвигали к подходу ранее:


  1. Мы говорили про то, что релизы не должны мешать друг другу и разработке.


  2. А также о том, что между релизами должна сохраняться консистентность и мы не хотим ею рисковать.


  3. И подход должен масштабироваться:



  • В ширину на большое количество версий.
  • В глубину на разные уровни патчей.


Кажется, что наш подход этому всему удовлетворяет:


  1. Одновременные релизы друг другу не мешают за счет того, что мы используем release branches и релиз master branches. Разработка всегда может вестись в master branches. И поэтому никакие работы с релизами не мешают разработчикам вносить новые изменения.


  2. Консистентность между релизами сохраняется за счет интеграции сверху вниз: master-first или upstream first, когда мы точно знаем, что промержили коммит во все более новые версии, если он есть в более старой.


  3. Масштабирование в ширину мы достигаем за счет того, что мы можем добавлять master branches. А масштабирование в глубину мы достигаем за счет того, что будем создавать такие branches, как 1.1.1-master и т. д. Они будут со своим релизным мастером относиться так же, как релизный мастер относится к обычному мастеру.




Какие проблемы у нас все еще остаются?



Первая проблема это проблема с тем, как мы боремся с нарушениями процессов.


Естественно, ни один процесс не будет работать, если ему не следовать. Но нужно сказать, что этот принцип upstream first, которого мы придерживаемся, он более хрупкий. За счет того, что мы не вмерживаем старые релизные branches вверх, если мы в какой-то момент что-то куда-то забыли промержить, т. к. merges между ветками мы не делаем, то фикс может куда-то и не попасть. И это проблема.


Поэтому, если процесс нарушается, то начинается хаос. И решаем мы это через то, что пишем дополнительные инструменты. Сейчас у нас есть первая версия инструмента, который делает нам валидацию git logа и Jira. Здесь нам очень помогает то, что мы делаем merge --squash и то, что у нас ровно один коммит под каждую Jira issue.


Скрипт может посмотреть на список коммитов на fix version, указанной в Jira и точно найти между ними соответствие 1 к 1. За счет этого можно легко поймать все проблемы, если мы что-то куда-то не промержили.



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


Представьте, что клиент использует версию 1.1.10 и захотел перейти на какую-то версию в ветке 1.2. На какую версию он может перейти? Может ли он перейти на 1.2.1?


На самом деле мы этого не знаем.


Проблема в том, что 1.1.10 могла выйти позавчера, а 1.2.1 могла выйти 3 месяца назад. В 1.1.10 будет больше фиксов. И то, что клиент уже видел пофиксеным в своей текущей версии, окажется сломанный, если он перейдет на 1.2.1.


Это означает, что при переходе клиента с версии на другую minor-версию, нужно учитывать время выпуска версии и то, какие коммиты туда попали.



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


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


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


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


Можем сделать выводы. О чем сегодня поговорили?



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

  • Нам нужно не забывать о сохранении консистентности и о том, что мы должны промержить коммиты сразу в несколько местах.


  • И мы должны убедиться, что выпуск релизов не мешает нам производить какие-то изменения в продукте или выпускать другие релизы.



  1. Github Flow, Git Flow, какие-то подходы, описание которых мы могли найти публично, этим требованиям не удовлетворяют. Хотя, я уверен, что у всех продуктовых компаний, которые занимаются такой поддержкой, есть какие-то свои собственные велосипеды на этот счет.


  2. Поэтому мы тоже построили свой собственный велосипед. И решили им поделиться.



  • Наш подход основан на интеграции master-first или upstream first сверху вниз и использования release master branches, которые аккумулируют изменения, соответствующие поддерживаемым miner-веткам.



  1. И продолжаем его улучшать и дорабатывать.

  • Мы работаем над дополнительными инструментами такими, как: кросс-валидация Git и Jira.


  • А также работаем над инструментами, которые помогут нам понимать соотношение между нашими версиями.



Спасибо за внимание!



Здравствуйте! Спасибо за доклад! Не могли бы вы чуть более подробно рассказать про выбор мастер first? Получается, что баг приходит на конкретную версию, допустим, на 1.3. И если баг не понятен, то коммитить его будут тоже на версии 1.3. Соответственно, в 1.3 в target его можно легко починить и дальше следуя логическому процессу разработки эволюции решения перенести его во все последующие ветки.


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


Спасибо за хороший вопрос! Можно было бы сказать, что тут есть какой-то компонент того, что так исторически сложилось. Мы сначала пришли к тому, что у нас было upstream first. Это достаточно давно произошло. Кросс-валидация Git и Jira, т. е. контроль за merge у нас появился не так давно. Но он тоже зависит от upstream first, потому что, если мы только что промержили что-то в 1.3 и еще не промержили выше, то вот этот бот, который к нам ходит и присылает нотификации, он сразу начнет сыпать алертами, что мы что-то еще не промержили.


Мы хотим, чтобы у нас были не алерты, на которые мы реагируем, а мы хотим, чтобы у нас алертов не было, потому, если бот постоянно будет сыпать тем, что у нас все баги, которые мы фиксим, должны быть куда-то еще помержены, то люди перестанут на это реагировать.


Добрый день! Спасибо за доклад! Какая политика при случае отката, если коммит не взлетел либо в конкретной версии, либо по всей ветке?


У нас редко делаются откаты. Прямо очень редко. Они хендляться в супер ручном режиме. Как предыдущий коллега говорил о том, что нам нужно провалидировать фикс, например, у пользователя, да, это так. Но если мы сделали какой-то фикс в мастере, и он не взлетел, проблемы не пофиксил, то мы его не просто так сделали. Мы нашли и воспроизвели какую-то проблему, мы что-то пофиксили. Иногда бывает так, что мы пофиксили проблему, но это не была та проблема, с которой приходил пользователь. Это означает, что мы что-то пофиксили, а теперь нам надо пофиксить что-то еще, т. е. откатывать нам ничего не нужно.


Если performance упал?


Если у нас была какая-то регрессия по performance, по чему-то еще, то мы, скорее всего, тоже не будем делать отката. Мы заведем отдельный regression issue и будем хендлить его таким образом.


Если у release engineer есть план, ему разработчик что-то замержил в ветку, это как согласовывается?


Мы на уровне правил проекта на Github лочим ветки соответствующим релизом.


Он замержил в мастер, правильно?


Да, это означает, что у нас регрессия появилась в куче релизных мастеров. И это означает, что мы заведем regression issue, какой-то блокер, который будет блокировать, возможно, релизы во всех мастерах. И мы постараемся быстро его пофиксить.


Это хороший вопрос. У нас, наверное, не так часто случаются такие проблемы.


Все frameworks идут по пути, когда все хорошо, но не всегда же это так. Ни один framework не задает ситуации, когда что-то сломалось.


Я согласен. Но здесь мы решаем проблему 99 % случаев. И 1 %, когда мы дропнули performance каким-то bugfixом в 2 раза и нашли это во время тестирования, а bugfix уже везде промержен, то мы в ручном режиме примем какое-то решение. Может быть, мы сделаем откат, но, скорее всего, мы очень быстро будем фиксить это по всем веткам.


Добрый день! Меня зовут Дмитрий, Информационная система Кодекс. Вы говорите, что вы используете подход upstream first, но при этом, допустим, к вам пришел тикет на исправление версии 1.3. Соответственно, разработчик сначала должен найти и исправить этот баг в 1.3, а затем пойти сверху в 1.5, 1.4, возможно, 1.2? Или же он начинает с самой последней версии в 1.5 и смотрит есть ли этот баг в самой свежей версии?


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


Когда мы анализируем проблему и когда мы ее воспроизводим, мы удостоверяемся, что она воспроизводится только на его версии или она воспроизводится еще на мастере. Если она воспроизводится еще и на мастере, то мы ее просто фиксим в мастере и потом протаскиваем назад. Если только на каком-то диапазоне версий, то, скорее всего, мы начнем фиксить с самой последней версии, где она воспроизводится. И потом начнем промерживать вниз.


Поиск начинается с версии пользователя?


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


И еще вопрос. Мастер в вашем примере, который вы приводили, это master-1.6?


Он не станет master-1.6. Когда-нибудь master-1.6 от него отбранчуется. Но фактически да, фактически мастер это релизная ветка для следующего релиза, который мы будем готовить.


И еще маленький вопрос. Версионирование там больше трех, больше вложенностей. И это специфика конкретно вашей разработки? Т. е. по факту находятся какие-то баги, вы их фиксите, но вряд ли получается так, что исправление каким-то кастомерам нужно, каким-то кастомерам не нужно, если это какой-то баг. Т. е. почему не выпускать 1.3, 1.3.1, 1.3.2, 1.3.3 и т. д?


Я понял вопрос. Т. е. почему кастомер не возьмет и не апгрейдится до самого конца, если ему все равно нужны эти все фиксы?


В каком-то смысле, да. И это еще решит ту проблему, что branches копятся. Тогда по факту мы сможем удалять, условно, предпоследнюю ветку всегда в рамках минорных версий. Т. е. мы выпустили 1.3.3, мы можем удалить 1.3.1.


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


Почему нам нужно поддерживать старые ветки, почему кастомеры не переходят? Это всегда какая-то договоренность с кастомерами, по тому, насколько большой прыжок они готовы сделать. Если они сидели полтора года в production и у них все было хорошо, а потом они нашли какой-то один баг, и мы им говорим: Отлично, вы теперь затяните все наши изменения и фичи за полтора года для того, чтобы его пофиксить, то они, скорее всего, будут не очень сильно этому рады. Даже если это захочет сделать сама команда разработки в каком-то банке, то их, скорее всего, развернут какие-то их operation. Они попросят chance list для такого перехода. А в нем будет 1 000 изменений. И они скажут: А можно нам патчик?.


Разве это не проблема версионирования? Получается, что у вас минорные версии на самом деле не минорные.


Почему? Мы выбираем и выпускаем минорную или мажорную версию просто по изменениям. Major ломает compatibility, а minor не ломает. Формально не ломает, по крайней мере. Но в рамках минорной или мажорной версии мы потом продолжаем независимо выпускать на них патчи, чтобы кастомеры, один раз выйдя в prod на минорной версии, было проще в рамках нее апгрейдиться.

Подробнее..

Организация кодовой базы и тестирования в монорепозиторий

09.10.2020 16:18:18 | Автор: admin

Всем привет. Меня зовут Илья, я фронтенд-разработчик изюнита BuyerX вАвито. Хочу поделиться тем, каким образом унас вкоманде организовано хранение кодовой базы, почему мы пришли киспользованию монорепозитория и как улучшаем DX-работы сним, а также кратко рассказать проорганизацию тестирования.



Текущее положение дел


Юнит BuyerX отвечает застраницы и функциональность, которая помогает пользователю выбирать товары наАвито. То есть мы стараемся сделать пользователя покупателем. Кнашей зоне ответственности относятся главная страница, страницы объявлений и страницы споисковой выдачей. Страницы споисковой выдачей могут быть специфичными подопределённые категории: например, где-то не нужны поисковые фильтры или нужен особый заголовок страницы и расположение самих элементов.



Главная страница Авито



Страница поисковой выдачи



Страница объявления


Разработка этих страниц вызывала определённые проблемы:


  • Все шаблоны жили вогромной основной кодовой базе, где было сложно ориентироваться и вносить изменения.
  • После внесения даже маленьких изменений сборка проекта занимала продолжительное время до5-10 минут вхудшем случае и потребляла большое количество ресурсов компьютера.
  • Когда хотелось, чтобы отдельные компоненты работали наReact-е, приходилось дублировать вёрстку и вшаблоне, и вкомпоненте длятого, чтобы сделать механизм серверного рендеринга.

Кроме того, главная страница, страницы объявлений и страницы споисковой выдачей позволяют создать непрерывный сценарий покупки дляпользователя. Поэтомув своё время мы приняли решение переписать их слегаси-технологии Twig наReact, чтобы вбудущем перейти наSPA-приложение, а также оптимизировать процесс загрузки компонентов длякаждой изстраниц. Так, кпримеру, сниппет объявления наглавной и странице поиска одинаковый. Тогда зачем грузить его два раза?


В связи сэтим появился npm-пакет, который мы гордо назвали single-page. Задача этого пакета содержать внутри себя верхнеуровневое описание каждой изстраниц. Это описание того, изкаких React-компонентов состоит страница, и вкаком порядке и месте они должны быть расположены. Также пакет призван управлять загрузкой нужных и выгрузкой уже ненужных компонентов, которые представляют собой небольшие React+Redux приложения, вынесенные вотдельные npm-пакеты.


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


Сам пакет single-page уже работает как описано. Однако длятого, чтобы все описанные механики приносили пользу, переход между страницами должен быть бесшовным, как вSPA-приложениях. Ксожалению, намомент написания статьи бесшовных переходов между страницами нет. Но это не значит, что их не будет. То, каким образом сейчас работает пакет single-page это основа, которую мы будем развивать дальше. Она уже задала определённые правила, связанные сорганизацией кодовой базы, которых мы вюните придерживаемся.


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


Отдельные репозитории для npm-пакетов


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


Это немного похоже навёрстку черезReact-компоненты, но проблема была втом, что вовсех шаблонах было много бизнес-логики, которая усложняла процесс чтения и внесения изменений. Плюс, из-за того, что каждая страница это отдельный шаблон, припереходах пользователя между страницами приходилось грузить всю страницу заново, даже если некоторые компоненты переиспользовались междушаблонами. Это увеличивало время ответа приобращении пользователя закакой-либо страницей, что не лучшим образом сказывалось наUX и SEO.


Стало понятно, что необходимо переходить нановый стек React. Переход проходил поэтапно. Сначала вюните договорились, что все новые компоненты будут написаны сразу наReact-е и будут рендериться настраницу послееё загрузки. Эти компоненты слабо влияли наSEO, поэтому подход имел право нажизнь. Пример такого компонента блок спросмотренными и избранными объявлениями наглавной странице:



Для работы новых компонентов наReact-е иногда нужны были уже существующие компоненты, написанные наTwig-е. Поэтому мы начали переносить некоторые изних наReact вурезанном виде. Так, кпримеру, сниппет, который используется вблоке просмотренных объявлений, был частично перенесён нановый стек, хотя наTwig весь шаблон сразличными условиями, влияющими наинформацию всниппете, содержал более 1000строк.



Сниппет вблоке просмотренных объявлений, который был перенесён сразу нановый стек


А вот как выглядят сниппеты вразличных категориях:



Сниппет вкатегории бытовой электронике



Сниппет вкатегории работа



Сниппет вкатегории недвижимость



Сниппет вкатегории автомобили


Вынос вnpm-пакет это только часть работы. Длятого, чтобы пакет был полезен, он должен быть использован восновной кодовой базе. Поскольку все компоненты это отдельные пакеты, то вмонолите (основной кодовой базе) необходимо подключить их как зависимости, а далее проинициализировать эти пакеты вкоде. Так как блок просмотренных объявлений и сниппет были выделены вотдельные npm-пакеты, то вкодовой базе монолита они были подключены как зависимости. Чтобы увидеть изменения, которые появились сновой версией пакета, достаточно поднять его версию безвнесения каких-либо дополнительных изменений.


Как видите, между пакетами уже появляются зависимости: монолит зависит откомпонента блока просмотренных и избранных объявлений, который всвою очередь зависит откомпонентов сниппета. Но вданном случае связь небольшая, поэтому после внесения изменений вnpm-пакет сниппетов необходимо:


  • поднять его версию;
  • опубликовать её;
  • подключить новую версию вкомпоненте правого блока;
  • поднять его версию;
  • поднять версию вмонолите.

Это может звучать сложно, но наделе процесс занимал минуты две и не требовал особых навыков.


Но продукт не стоял наместе. Он развивался и появлялись новые компоненты, например, компонент технических характеристик дляавтомобилей. Кроме того, активно переписывались такие старые компоненты как поисковые фильтры. Количество пакетов постепенно росло, и начали появляться новые проблемы.


Между пакетами стало появляться больше зависимостей, и не каждый инженер знал оних всех. Иногда даже мы вюните могли о чём-то забыть, а разработчик изсоседней команды вполне мог не знать осуществовании отдельного npm-пакета, который содержит взависимостях изменяемый пакет. Из-заэтого впакетах могли использоваться разные версии зависимого пакета. Плюс, так как каждый npm-пакет был отдельным репозиторием, количество пул-реквестов сильно выросло: вкаждый репозиторий npm-пакета делался пул-реквест сизменением версии самого пакета и его зависимостей.


Уподхода, когда каждый npm-пакет жил всвоём репозитории, был и свой плюс. Приподнятии версии зависимости вкаком-нибудь пакете, необходимо было убедиться, что этот пакет не сломается приработе насайте. То есть нужно было протестировать все внесённые изменения. Проверки побольшей части приходилось делать руками существовавшего набора тестов и инструментария было недостаточно дляпокрытия большинства сценариев. А принахождении каких-либо багов втестируемом пакете, их нужно было исправить. Поэтому нередко присутствовала практика, когда версию зависимости поднимали не везде, а только там, где это необходимо. Содной стороны, это усугубляло рассинхронизацию версий зависимых пакетов, а с другой сильно упрощало тестирование засчёт отсутствия некоторых проверок.


Однако вкакой-то момент рассинхронизация версий зависимостей привела кновым проблемам: пакет мог содержать сильно старую зависимость и простое её обновление могло сломать работу всего пакета. Из-заэтого приходилось тратить лишнее время наактуализацию зависимостей, внесение правок всам пакет и, возможно, взависимые тоже, а также натестирование этого пакета. Конечно, вкаждом репозитории были тесты, чтобы проверить, что всё работает корректно. Но тесты были только скриншотные, что ограничивало круг покрываемых вещей. Плюс не вовсех репозиториях был подключен CI, чтобы тесты прогонялись накаждом пул-реквесте.


Что получилось наэтом этапе:


  1. Количество связанных пакетов выросло.
  2. Каждый пакет жил вотдельном репозитории.
  3. Вкаждый репозиторий создавался пул-реквест свнесением изменений, связанных споднятием версий зависимости.
  4. Ситуация, когда пакет не имел последнюю актуальную версию зависимости была нормой. Плюс, кэтому моменту уже создавался пакет single-page, который взависимостях имел все ранее созданные пакеты.

Всё это привело к тому, что мы начали искать пути дляулучшения работы срепозиториями и всеми нашими пакетами.


Переход к монорепозиторию


Поиск инструментов привёл нас кLerna. Lerna опенсорсный инструмент дляработы смонорепозиториями. Он позволил бы нам хранить все пакеты вмонорепозитории, и забрал бы часть работы посинхронизации версий насебя. Тогда мы смогли бы не заботиться отом, чтобы поднимать все версии пакетов руками, а главное иметь прозрачную кодовую базу совсеми зависимостями.


После небольшого эксперимента и ресёрча, стало понятно, что Lerna поможет решить часть наших проблем:


  • С ней не будет необходимости вкаждом пакете самим поднимать версии зависимых пакетов.
  • Отпадёт необходимость постоянно помнить прозависимости, потому что Lerna знает, какие пакеты какими версиями связаны.
  • Количество пул-реквестов уменьшится доодного, вкотором видны все зависимости, которые будут изменены.

Мы завели отдельный репозиторий, вкоторый начали переносить все пакеты и связывать их зависимостями черезLerna.


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


Длярешения этой задачи внутри нашего юнита нашелся доброволец, который хорошо разобрался вособенностях работы Lerna и поделился знаниями намастер-классе. Но как быть состальными? Как быть сновыми разработчиками, которые приходят вкомпанию и вносят свои изменения? Проводить мастер-класс каждый раз не будешь. ВReadMe инструмента, как и внутри нашего монорепозитория, есть инструкция дляработы, но она не всегда помогает. Из-занепонимания случалось следующее:


  • врепозитории обновлялись лишние пакеты;
  • восновной кодовой базе монолита поднято меньше зависимостей, чем должно быть;
  • или наоборот зависимостей поднято больше, чем должно быть.

Кроме того, перед тем, как опубликовать пакет, необходимо обновить длянего changelog. Вбольшинстве случаев он является копипастой, но её необходимо повторить внескольких репозиториях. Дляодного-двух это не проблема, но когда пакетов становится десяток, легко где-то допустить ошибку или забыть добавить запись вchangelog. А это значит, что придётся вносить исправления и ждать, когда завершит свою работу билд CI.


Возникшие проблемы мы решили черезавтоматизацию. Дляэтого написали специальный скрипт, который:


  • находил все зависимые пакеты;
  • поднимал вних dev или latest версию взависимости отпотребности;
  • добавлял changelog всем пакетам;
  • заменял новые версии вpackage.json файле монолита нановые и, вслучае dev пакетов, ещё и публиковал их.

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


Работа CI


Остаётся ещё один вопрос, который хочется подсветить: CI.


Так как репозиторий один, то и все тесты гоняются нанём сразу. Кроме того, появился внутренний инструмент, который позволяет писать компонентные тесты сиспользованием библиотеки Enzyme. Его написали ребята изплатформенной команды Авито и рассказали онём вдокладе Жесть дляJest. Это позволило покрыть сценарии, которые раньше нельзя было проверить. Так, например, появилась возможность проверить вызов попапа приклике на кнопку все характеристики впакете стехническими характеристиками дляавтомобилей.


В результате накаждый пул-реквест прогоняется весь набор имеющихся тестов. Теперь тесты могут дать определённую гарантию того, что приподнятии версии зависимого пакета ничего не сломается. Но есть и минусы: количество пакетов вмонорепозитории растёт, сним растёт и количество тестов. Как следствие, растёт и время их прогона. Приэтом кажется, что нет смысла гонять тесты там, где нет никаких изменений. А значит, можно сократить время выполнения билда вбудущем. Внутренний инструмент продолжает развиваться, и уже сейчас внём появился механизм дляпрогона определённого скоупа тестов. Именно этот механизм и будет использоваться дляуменьшения выборки тестов и сокращения времени выполнения билда.


Итоги и планы


Задва года мы прошли процесс перехода отбольшого количества слабо связанных репозиториев доавтоматизации работы смонорепозиторием черезLerna. Приэтом, есть гарантия того, что всё будет работать корректно благодаря прогону тестов накаждом пул-реквесте. Количество самих пул-реквестов уменьшилось с8-9 вхудшем случае додвух: вмонолит и вмонорепозиторий. Приэтом пул-реквест вмонорепозиторий содержит сразу все изменения.


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

Подробнее..

Code review в Gitlab CE если Merge request approvals нет, но очень хочется

24.06.2020 18:08:11 | Автор: admin

Одной из самых нужных функций, которой нет в бесплатной версии GitLab, является возможность контролировать Merge request (MR), используя обязательный code review.

Сделаем минимальный функционал сами запретим Merge, пока несколько разработчиков не поставят палец вверх на MR.



Зачем это вообще?



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

В итоге приходится:
  • либо совсем запрещать Merge в защищенные ветки для части разработчиков, но тогда разработчики, имеющие право на Merge, получают конфликты при слиянии чужих MR как бонус;
  • либо давать возможность делать бесконтрольные слияния с вашей мастер-веткой без code review, даже если это Junior, устроившийся только вчера.


Первым же делом отправился гуглить, полагая, что уж точно кто-то что-то подобное уже сделал (без доработки кода), но оказалось, что подобной реализации в community версии еще не было.

Общая схема работы



В качестве примера настроим Merge request approvals на тестовом репозитории myapp
gitlab.com/gitlab-ce-mr-approvals/myapp

  1. Создадим токен для доступа к API GitLab (через него будем получать информацию о количестве голосов за и против)
  2. Добавим токен в переменные GitLab
  3. Запретим Merge при ошибках в пайплайне (если голосов за недостаточно)
  4. Настроим проверку голосов как часть пайплайна CI/CD
  5. Запретим делать коммиты в защищенные ветки, все изменения проводим только через MR
  6. Проверим, что получилось в итоге


1. Создаем токен для доступа к API



Заходим в Настройки пользователя Токены доступа и записываем токен


Учетная запись для получения токена
Доступ к API позволяет делать практически все с вашими репозиториями, поэтому советую создать отдельную учетную запись Gitlab, дать ей минимальные права на ваши репозтории (например, Reporter) и получить токен для этой учетной записи.



2. Добавляем токен в переменные Gitlab



Например, на предыдущем шаге мы получили токен QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Открываем Настройки CI/CD Переменные Добавить переменную GITLAB_TOKEN_FOR_CI



В итоге получим:



Это можно сделать как на одном репозитории, так и на группе репозиториев.

3. Ставим запрет на Merge, если не получены одобрения коллег после проведенного code review



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

Заходим в Настройки Основные Запросы на слияние Проверки слияния и включаем опцию Сборочные линии должны успешно выполниться


4. Настраиваем пайплайн



Если вы еще не делали CI/CD конвейер для вашего приложения
Создаем в корне репозитория файл .gitlab-ci.yml с простейшим содержанием

stages:  - build  - testvariables:  NEED_VOTES: 1include:  - remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"run-myapp:  stage: build  script: echo "Hello world"




Отдельный репозиторий для конфигурации CI/CD
Я бы рекомендовал сделать отдельный репозиторий, в котором необходимо создать файл myapp.gitlab-ci.yml для настройки конвейера. Так вы сможете лучше контролировать доступ участников, которые могут изменить конвейер сборки и получить токен доступа.

Расположение нового файла конвейера нужно будет указать, зайдя в репозиторий myapp Настройки CI/CD Сборочные линии Пользовательский путь конфигурации CI указать новый файл, например myapp-ci.gitlab-ci.yml@gitlab-ce-mr-approvals/ci


Совет: используйте линтер для внесения изменений в файлы пайплайна
Даже если вы работаете один, хорошим помощником выступит работа через MR, прогоняя все ваши изменения файлов пайплайна через линтер. Если вы ошибетесь в синтаксисе YAML-файла, это не даст вам сломать рабочий конвейер, а просто заблокирует Merge.

Пример контейнеров с линтерами, которые вы можете встроить в ваш пайплайн:
hub.docker.com/r/gableroux/gitlab-ci-lint
hub.docker.com/r/sebiwi/gitlab-ci-validate

И пример стадии проверки:

stages:  - lintlint:  image: sebiwi/gitlab-ci-validate:1.3.0  variables:    GITLAB_HOST: https://gitlab.com  script:    - CI_FILES=(./*.yml)    - for f in "${CI_FILES[@]}"; do        gitlab-ci-validate $f;      done;




Осталось добавить в ваш пайплайн несколько параметров, чтобы все заработало:

stages:
- test

variables:
NEED_VOTES: 1

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"


Переменная NEED_VOTES определяет сколько пальцев вверх должно быть у MR, чтобы был доступен Merge. Значение, равное единице, означает, что вы сами можете одобрить свой MR, лайкнув его.

include подключает стадию test, проверяющую количество лайков.

Простейший пайплайн на примере myapp.gitlab-ci.yml
stages:
- build
- test

variables:
NEED_VOTES: 0

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

run-myapp:
stage: build
image: openjdk
script:
- echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- java HelloWorld.java



Содержание check-approve.gitlab-ci.yml
ci-mr:
stage: test
script:
- echo ${CI_API_V4_URL}
- echo "CI_PROJECT_ID ${CI_PROJECT_ID}"
- echo "CI_COMMIT_SHA ${CI_COMMIT_SHA}"
- "export MR_ID=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .id else {} end\" | grep --invert-match {})"
- "export MR_TITLE=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .title else {} end\" | grep --invert-match {})"
- "export MR_WIP=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .work_in_progress else {} end\" | grep --invert-match {})"
- "export MR_UPVOTES=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .upvotes else {} end\" | grep --invert-match {})"
- "export MR_DOWNVOTES=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .downvotes else {} end\" | grep --invert-match {})"
- MR_VOTES=$(expr ${MR_UPVOTES} - ${MR_DOWNVOTES})
- NEED_VOTES_REAL=${NEED_VOTES:-1}
- echo "MR_ID ${MR_ID} MR_TITLE ${MR_TITLE} MR_WIP ${MR_WIP} MR_UPVOTES ${MR_UPVOTES} MR_DOWNVOTES ${MR_DOWNVOTES}"
- echo "MR_VOTES ${MR_VOTES} Up vote = 1, down vote = -1, MR OK if votes >=${NEED_VOTES_REAL}"
- if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ];
then
echo "MR OK";
else
echo "MR ERROR Need more votes";
exit 1;
fi
image: laptevss/gitlab-api-util
rules:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^release\/.*$/'



Подробнее о том, что происходит при проверке:
  • установлено ограничение, что проверка будет только при создании MR в ветки master или release/*
  • используя API GitLab, получаем количество лайков и дизлайков
  • вычисляем разность между положительными и отрицательными откликами
  • если разность меньше заданного нами значения в NEED_VOTES, то блокируем возможность сделать слияние


5. Запрещаем коммиты в защищенные ветки



Определяем ветки, для которых мы должны проводить code review и указываем, что работать с ними можно только через MR.

Для этого заходим в Настройки Репозиторий Protected Branches


6. Проверяем



Зададим NEED_VOTES: 0

Делаем MR и ставим дизлайк.



В логах сборки:


Теперь ставим лайк и запускаем повторную проверку:
Подробнее..

О системах контроля версий

30.09.2020 12:15:28 | Автор: admin
Всем привет! Уже на следующей неделе в OTUS стартует Супер-практикум по использованию и настройке GIT. Этому я и решил посвятить сегодняшнюю публикацию.



Введение


Предлагаю обсудить предназначение и различные способы организаций систем контроля версий.


Системы контроля версий


Система контроля версий является прежде всего инструментам, а инструмент призван решать некоторый класс задач. Итак, система контроля версий это система, записывающая изменения
в файл или набор файлов в течение времени и позволяющая вернуться позже к определенной версии. Мы хотим гибко управлять некоторым набором файлом, откатываться до определенных версий в случае необходимости. Можно отменить те или иные изменения файла, откатить его удаление, посмотреть кто что-то поменял. Как правило системы контроля версий применяются для хранения исходного кода, но это необязательно. Они могут применяться для хранения файлов совершенно любого типа.

Как хранить различные версии файлов? Люди пришли к такому инструменту как системы контроля версий не сразу, да и они сами бывают очень разные. Предложенную задачу можно решить с применением старого доброго copy-paste, локальных, централизованных или распределенных систем контроля версий.

Copy-paste


Известный метод при применении к данной задаче может выглядеть следующим образом: будем называть файлы по шаблону filename_{version}, возможно с добавлением времени создания или изменения.

Данный способ является очень простым, но он подвержен различным ошибкам: можно случайно изменить не тот файл, можно скопировать не из той директории (ведь именно так переносятся файлы в этой модели).

Локальная система контроля версий


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

Одним из примеров таких систем является система контроля версий RCS, которая была разработана в 1985 году (последний патч был написан в 2015 году) и хранит изменений в файлах (патчи), осуществляя контроль версий. Набор этих изменений позволяет восстановить любое состояние файла. RCS поставляется с Linux'ом.

Локальная система контроля версий хорошо решает поставленную перед ней задачу, однако ее проблемой является основное свойство локальность. Она совершенно не преднезначена для коллективного использования.

Централизованная система контроля версий


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

Для организации такой системы контроля версий используется единственный сервер, который содержит все версии файлов. Клиенты, обращаясь к этому серверу, получают из этого централизованного хранилища. Применение централизованных систем контроля версий на протяжении многих лет являлась стандартом. К ним относятся CVS, Subversion, Perforce.

Такими системами легко управлять из-за наличия единственного сервера. Но при этом наличие централизованного сервера приводит к возникновению единой точки отказа в виде этого самого сервера. В случае отключения этого сервера разработчики не смогут выкачивать файлы. Самым худшим сценарием является физическое уничтожение сервера (или вылет жесткого диска), он приводит к потерю кодовой базы.

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

Распределенная система контроля версий


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

Все копии являются равноправным и могут синхронизироваться между собой. Подобный подход очень напоминает (да и является) репликацией вида master-master.

К данному виду систем контроля версий относятся Mercurial, Bazaar, Darcs и Git. Последняя система контроля версий и будет рассмотрена нами далее более детально.

История Git


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

Заключение


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

Подробнее..

И полгода не прошло выпущена система управления версиями Git 2.29

21.10.2020 20:04:14 | Автор: admin

Привет, %username%, сегодня отличная новость: в открытом доступе появился выпуск распределенной системы управления версиями Git 2.29.0. Наверное, на Хабре не стоит рассказывать, что это такое, ведь Git по-прежнему остается одной из лучших систем.

В новом выпуске сразу 627 изменений, которые внесли 89 разработчиков. О главных изменениях и доработках рассказываем под катом.

  • Начнем с экспериментальной возможности использования алгоритма хэширования SHA-256 вместо скомпрометированного SHA-1 при записи объектов в репозиторий. Сейчас хэш формируется на основе содержимого каждого объекта в Git и является его уникальным идентификатором. При любой попытке изменения данных или заголовков объекта выполняется изменение идентификатора. Тем не менее, SHA-1 был скомпрометирован, поэтому Git решено перевести на новый уровень защиты. Изначально планировалось использовать SHA3-256, но в итоге разработчики воспользовались SHA2-256, поскольку SHA2 уже применяется в Git для цифровых подписей. Было принято здравое решение не добавлять новый алгоритм, поскольку если хотя бы один из них скомпрометируют, то это приведет к проблемам с безопасностью. Чем больше элементов в системе, тем выше вероятность, что что-то пойдет не так логика понятна.

  • Сейчас в Git добавлена возможность включения нового формата объектов при создании репозитория:

$ git init --object-format=sha256 repo
Initialized empty Git repository in /home/ttaylorr/repo/.git/

$ cd repo
$ echo 'Hello, SHA-256!' >README.md
$ git add README.md
$ git commit -m "README.md: initial commit"
[master (root-commit) 6e92961] README.md: initial commit
1 file changed, 1 insertion(+)
create mode 100644 README.md

$ git rev-parse HEAD
6e929619da9d82c78dd854dfe237c61cbad9e95148c1849b1f96ada5ee800810


Выбрать можно лишь между SHA-1 и SHA-256, возможности сочетать разные хеши в одном репозитории нет.

  • В командах git fetch и git push появилась поддержка исключающих спецификаций ссылок, которые расширяют правила сопоставления ссылок между ветками в локальном и внешнем репозиториях. Эта возможность окажется полезной в ситуациях, когда необходимо не только выбрать, но и исключить некоторые ветки из сопоставления. Так, когда нужно извлечь все ветки refs/heads/*, кроме одной refs/heads/ref-to-exclude, раньше приходилось указывать полный список с использованием такого скрипта:

$ git ls-remote origin 'refs/heads/*' |
grep -v ref-to-exclude |
awk '{ print $2:$2 }' |
xargs git fetch origin


  • Сейчас появился оператор исключения "^". Выражения с этим оператором допускают шаблоны, но не могут ссылаться на идентификаторы объекта. Команда с использованием нового оператора может выглядеть следующим образом:

$ git fetch origin 'refs/heads/*:refs/heads/*' ^refs/heads/ref-to-exclude

Кроме того, в настройках можно использовать исключения:

$ git config --add remote.origin.fetch ^refs/heads/foo

  • В git shortlog теперь появилась возможность группировки коммитов по содержимому дополнительных полей, Reviewed-by: и Coauthored-by:, а не только по автору или коммитеру. Так что если необходимо вывести список наиболее активно рецензирующих разработчиков, то нужна команда:

$ git shortlog -ns --group=trailer:reviewed-by v2.28.0.. | head -n5
40 Eric Sunshine
10 Taylor Blau
4 brian m. carlson
2 Elijah Newren
1 Jeff King


  • Можно указывать несколько выражений "--group" при запуске и использование опции "--format". Так что для учета соавторов или помощников теперь нужно указывать вот что:

$ git shortlog -ns --group=author --group=trailer:co-authored-by
$ git shortlog --format="...helped %an on %as" --group=trailer:helped-by v2.28.0..v2.29.0


  • Если возникает конфликт в процессе выполнения операции git merge, заголовок сообщения о коммите теперь помещается в скобки для явного отделения данных из коммита от диагностических сообщений Git.
  • Разработчики вернули отключенную в выпуске 2.27 вторую версию коммуникационного протокола Git. Таким образом, устранена ошибка, которая приводила к проблемам со стабильностью.
  • В команду git bisect, которая используется для выявления ревизии, добавлена опция "--first-parent" для изменения отбора коммитов, проходящих между заведомо рабочей ревизией и ревизией, в которой зафиксировано проявление проблемы.

Просмотреть обо всех новшествах можно здесь.

Подробнее..

Recovery mode Мои пожелания к СУБД будущего, а также к Росреестру в части транзакционности

07.08.2020 08:23:27 | Автор: admin

Клиент взаимодействует с базой данных.
С сайта http://corchaosis.ru, автор картины Jonathan Tiong.

Помимо того, что я являюсь программистом (преимущественно, это Delphi + всякие разные СУБД, в последнее время ОРАКЛ, + немного PHP), у меня есть хобби это купля и продажа квартир. Я покупаю квартиру на этапе строительства от более менее надёжного застройщика по вкусной цене (например, сейчас таким застройщиком является Самолёт, квартиры возле м. Некрасовка продаются), дожидаюсь сдачи дома (часто на два года позже, с недорогими предложениями такое случается), делаю в ней ремонт и затем продаю за 95-100% её рыночной цены.

Так вот, я (как и все) столкнулся с проблемой отсутствия у РосРеестра транзакционности.

Проблема отсутствия у Росреестра транзакционности сделок

В программировании Транзакция, а в недвижимости это Сделка с альтернативой (а также, как её часть, Договор о банковской ячейке), и там всё немного более сложно. Рассказываю.

Вася пришёл на просмотр квартиры, которую продаёт Петя. И Васе всё очень понравилось, в том числе и цена, но у Васи денег нет. Так начинается наша история.

Вася имеет свою недвижимость, которая имеет какие-то не особо нужные для него ценности в соседнем доме жил Ломоносов, высота потолков семь с половиной метров, поблизости находится плодовощная база и рынок Садовод, можно дойти пешком на Аэроэкспресс, под квартирой есть подвал высотой 1 метр, над квартирой есть чердак удобный для астрономических наблюдений. Вася понимает что эти особенности повышают цену его квартиры, но не для него самого. И он решает квартиру Пети купить, а свою квартиру продать. Но продать именно для того чтобы купить квартиру Пети, а не просто. На языке риэлторов это называется Альтернатива подобрана.

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

Два эльфа Средиземья, Маглор и Маэдрос, обладают подходящей (критериям Пети) недвижимостью в городе Валинор, которую срочно распродают, так как отправляются служить Мелькору. На языке риэлторов это называется Свободная продажа.

Итак, Вася находит клиента Серёжу. Теперь, Петя находит два подходящих ему варианта в городе Валинор. Выходим на оформление сделки. Допустим для простоты, что никто из участников сделки не использует ипотеку и не имеет долевым собственником несовершеннолетних. Таким образом, теперь должны совершиться следующие действия:
1. Серёжа передаёт деньги Пете.
2. Вася передаёт свою квартиру Серёже.
3. Петя передаёт свою квартиру Васе.
4. Или Маглор, или Маэдрос, передают свою квартиру в Валиноре Пете и получают деньги Серёжи.
5. Малкор и Маэдрос идут в Мордор служить Мелькору.

Идеально было бы передать в Росреестр на выполнение следующий скрипт:
START TRANSACTION
Квартиру Васи отдать Серёже.
Квартиру Пети отдать Васе.
begin
Квартиру Малкора отдать Пете
Деньги Серёжи отдать Малкору
ЕСЛИ_ОШИБКА:
Квартиру Маэдроса отдать Пете
Деньги Серёжи отдать Маэдросу
end
COMMIT TRANSACTION

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

Однако, Росреестр не поддерживает транзакционность. Все действия будут выполняться последовательно и независимо, друг за другом, без отката транзакции в целом если не выполнилось одно из них. Максимум, что можно достичь учитывая, что Росреестр и МФЦ не работают с передачей наличных средств это заложить деньги в банковскую ячейку, с условиями доступа к ним Васи, Пети, Серёжи (если вообще никакая сделка не зарегистрирована), и иных действующих лиц, по факту предъявления ими зарегистрированных Росреестром договоров. (И кстати, банки самостоятельно проверку подлинности договоров не осуществляют, то есть доверяют подлинности бумаг участников сделки).

Кроме рисков неполного выполнения транзакции, другая проблема в том, что если другие участники могут въехать в своё новое жильё не дожидаясь полного оформления (привет, вопрос недоплаты коммунальных платежей!), то Маглор и Маэдрос нескоро отправятся служить Мелькору, и возможно, Маглор не сможет подержать в своих руках сильмариллы, он просто не успеет. Сделки с недвижимостью выполняются последовательно, и оформление каждой сделки будет длиться не менее чем 9 рабочих дней.

Кроме этого, Росреестр не поддерживает обременение строящегося по ДДУ жилья, а мог бы, это элементарное действие в отношении простого фьючеса.

Теперь перейдём к недостаткам и моим хотелкам про СУБД

1) Первое это отсутствие системы контроля версий. Если со стороны Delphi я веду разработку в своей песочнице, и сделанные мной изменения не появятся у других программистов до момента их коммита, то с СУБД не так. И даже если мне доверяют полный (по крайней мере, в рамках нужного для поставленной передо мной задачи) доступ к боевой БД, а такое случается, я не могу на ней разрабатывать. Пока я буду отлаживаться, всё рухнет. Это что за каменный век??? Сделайте песочницу разработчикам.

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

3) Третье и тут я воспользуюсь терминологией Оракла отсутствует возможность вызвать простой скрипт Insert или Update, использующий Returning, так, как мы вызываем Select. Возможно, это не проблемы Оракла, а проблемы стыка Delphi + Oracle.

4) Четвёртое необходимость назначения создаваемым мной процедурам и функциям полномочий там, где я делать этого не хочу. Я не хочу задавать, а потом менять, полномочия пользователей процедуре и функции. Почему, если я явно не написал Grant-ы, система не могла бы сама посмотреть на задействованные объекты, и в соответствии с правами на действия с ними наделять или нет тех или иных пользователей правом на вызов функции? Я готов написать для этого при написании функций и процедур одно ключевое слово. Или, ещё лучше, пусть пользователь начнёт выполнение, а если ветка алгоритма приведёт его к запросу на который у пользователя нет прав, то выкинет с ошибкой.
Подробнее..

CGit-UI web-интерфейс для Git-репозиториев

09.12.2020 10:19:32 | Автор: admin

cGit-ui это web-интерфейс для Git-репозиториев, основу которого предстваляет CGI-скрипт написанный на языке С.


cGit-ui поддерживает Markdown-файлы, которые обрабатываются на стороне сервера с помощью библиотеки md4c, зарекомендовавшей себя в проекте KDE Plasma. cGit-ui предоставляет возможность размещения кодов верификации сайта, а также скриптов от таких систем как Google Analytics и Yandex.Metrika для анализа трафика.


Пользователи cGit-ui получают широкие возможности для настройки как внешнего вида, так и функциональности собственного сайта, на котором они представляют свои репозитории. Кроме того, cGit-ui позволяет создавать и размещать на сайте, так называемые Donation-диалоги для приема пожертвований в пользу тех или иных проектов.


Внешний вид и функциональность сайтов, построенных на cGit-ui, можно рассмотреть на примере где, в том числе, представлены достаточно большие Git-репозитории, что позволяет примерно оценить скорость работы интерфейса. Рассматривать сайт в работе лучше начинать со смартфона, а затем переходить на более широкие экраны.


С момента выхода интерфейса к Subversion-репозиториям произошел ряд изменений в структуре пакетов, необходимых для установки. Так, например, cScm-демон, который служит для разбора конфигурационных файлов, выделен в отдельный пакет.


Поэтому в данной статье дается более развернутое описание cGit-ui.



Установку и настройку cGit-ui необходимо начинать с инсталляции cScm-демона, который одновременно может поддерживать как cSvn-ui, так и интерфейс к Git-репозиториям.



Инсталляция cScm-демона


cScm-демон служит для того, чтобы не нагружать лишней работой, связаной с разбором конфирурационных файлов, основные CGI-скрипты cSvn-ui и cGit-ui. cScm-демон преобразует список репозиториев /etc/cgit-ui.rc(5) в двоичный формат, который поступает на вход cGit-ui CGI-скрипта через разделяемую память. Таким образом CGI-скрипт не тратит время на синтаксический анализ списка репозиториев.


Исходный пакет cScm можно получить двумя способами: загрузить с FTP-сервера или с помощью Subversion:


svn checkout svn://radix.pro/cscm/tags/cscm-0.1.3 cscm-0.1.3

Если использован второй способ, то перед сборкой пакета необходимо приготовить исходные тексты для их последующего конфигурирования. Для этого нужно воспользоваться скриптом bootstrap:


cd cscm-0.1.3./bootstarp

который установит Autotools средства, соберет коллекцию aclocal.m4 и создаст configure скрипт.


Далее как обычно для пакетов использующих Autotools:


./configure --prefix=/usr \            --sysconfdir=/etc \            --with-controldir=/etc/rc.d \            --with-logrotatedir=/etc/logrotate.d \            --with-homepath=/var/lib \            --with-logdir=/var/log \            --with-piddir=/var/runmakemake install


Для запуска cScm-демона надо сделать следующие файлы исполняемыми:


chmod a+x /etc/rc.d/rc.csvndchmod a+x /etc/rc.d/rc.cgitd


Если же вы хотите запускать cscmd(8) демоны при старте системы, которая имеет BSD-like инициализацию, такой как Slackware, необходимо в скрипты /etc/rc.d/rc.M и /etc/rc.d/rc.6 добавить следующие строки, соответственно:


/etc/rc.d/rc.M:
# Start cSvn SCM daemon:if [ -x /etc/rc.d/rc.csvnd ] ; then  /etc/rc.d/rc.csvnd startfi# Start cGit SCM daemon:if [ -x /etc/rc.d/rc.cgitd ] ; then  /etc/rc.d/rc.cgitd startfi

/etc/rc.d/rc.6:
# Stop cSvn SCM daemon:if [ -x /etc/rc.d/rc.csvnd ] ; then  /etc/rc.d/rc.csvnd stopfi# Stop cGit SCM daemon:if [ -x /etc/rc.d/rc.cgitd ] ; then  /etc/rc.d/rc.cgitd stopfi


Для систем использующих systemd, необходимо установить файлы, подобные следующим:


/etc/systemd/system/csvnd.service:
[Unit]Description=The cSvn daemonAfter=network.target[Service]PIDFile=/var/run/csvnd.pidExecStart=/usr/sbin/cscmd --daemonize --inotify --scm=svn --pid=/var/run/csvnd.pid --log=/var/log/csvnd.log --config=/etc/csvn-ui.rcExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s TERM $MAINPID[Install]WantedBy=multi-user.target

/etc/systemd/system/cgitd.service:
[Unit]Description=The cGit daemonAfter=network.target[Service]PIDFile=/var/run/cgitd.pidExecStart=/usr/sbin/cscmd --daemonize --inotify --scm=git --pid=/var/run/cgitd.pid --log=/var/log/cgitd.log --config=/etc/cgit-ui.rcExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s TERM $MAINPID[Install]WantedBy=multi-user.target


Прежде чем запускать cscmd-демон надо создать конфигурационный файл с описанием репозиториев, например, /etc/cgit-ui.rc(5). После запуска демона в log-файле /var/log/cgitd.log можно будет видеть текущее состояние работы или описание ошибок, которые допущены в файле конфигурации.


Обратите внимание на опцию --inotify. Данная опция позволяет не посылать демону сигнал о том что надо перечитать конфигурационный файл после каждого редактирования настроек списка репозиториев. Демон самостоятельно будет отслеживать изменения в файле /etc/cgit-ui.rc(5).


Граматика файлов /etc/cgit-ui.rc(5) и /etc/csvn-ui.rc(5) элементарна. Посмотреть не нее можно в файле parse.y. Структура бинарного файла списка репозиториев описана в файле bcf.h.



Бинарные пакеты


Еще нет Linux-дистрибутивов, имеющих в пакетной базе программы cSvn-ui и cGit-ui. Однако пользователи могут самостоятельно собрать нужные им пакеты по инструкциям в каталоге doc/build-packages. Здесь есть наброски spec-файла для систем, использующих RPM, файл сборки пакета для ArchLinux, а также скрипт для Slackware.


Дополнительную информацию о cscmd(8) можно получить на странице руководства:


man 8 cscmd


Подготовка исходного пакета cGit-ui


Исходный пакет cGit-ui так же можно получить двумя способами: загрузить с FTP-сервера или с помощью Subversion:


svn checkout svn://radix.pro/cgit-ui/tags/cgit-ui-0.1.4 cgit-ui-0.1.4

Второй способ, как всегда, подразумевает использование скрипта bootstrap для подготовки к сборке:


cd cgit-ui-0.1.4./bootstarp


Требуемые пакеты


cGit-ui CGI-скрипт зависит от следующих библиотек: libpcre2, libmd4c, libmd4c-html, libmagic, libgit2.


Разумеется, для использования cGit-ui, в системе должен быть установлен web-сервер и какой-либо сервер приложений. Далее мы будем рассматривать связку Nginx + uWsgi, однако на ряду с uWsgi, пользователи могут выбрать CGI или FastCGI, которые поддерживаются сервером Nginx.



Инсталляция cGit-ui


Здесь необходимо только выбрать каталог, в который будут установлены, как сам CGI-скрипт, так и все необходимые компоненты web-сайта пользователя:


./configure --prefix=/usr \            --with-scriptdir=/var/www/htdocs/cgitmakemake install


После установки пакета необходимо отдать права на каталог пользователю, от имени которого работает web-сервер:


chown -R nginx:nginx /var/www/htdocs/cgit


uWsgi


Поскольку, на стадии конфигурирования исходых текстов, мы выбрали каталог установки --with-scriptdir=/var/www/htdocs/cgit, далее все настройки будут производиться относительно именно этого каталога. Конфигурационный файл сервера приложений /etc/uwsgi/cgit-ui.ini должен выглядеть следующим образом:


/etc/uwsgi/cgit-ui.ini:
[uwsgi]master          = trueplugins         = cgisocket          = /run/uwsgi/%n.sockuid             = nginxgid             = nginxprocname-master = uwsgi cgit-uiprocesses       = 1threads         = 2cgi             = /var/www/htdocs/cgit/cgit-ui.cgi

Здесь cgi = /var/www/htdocs/cgit/cgit-ui.cgi представляет полное имя CGI-скрипта cGit-ui.


Для запуска uWSGI-демона можно воспользоваться следующим скриптом:


/ets/rc.d/rc.cgit-ui-uwsgi:
#!/bin/sh## uWSGI daemon control script.#CONF=cgit-uiBIN=/usr/bin/uwsgiCONFDIR=/etc/uwsgiPID=/var/run/$CONF-uwsgi.piduwsgi_start() {  # Sanity checks.  if [ ! -r $CONFDIR/cgit-ui.ini ]; then # no config files, exit:    echo "There are config files in $CONFDIR directory. Abort."    exit 1  fi  if [ -s $PID ]; then    echo "uWSGI for cGit-ui appears to already be running?"    exit 1  fi  echo "Starting uWSGI for cGit-ui server daemon..."  if [ -x $BIN ]; then    /bin/mkdir -p /run/uwsgi    /bin/chown nginx:nginx /run/uwsgi    /bin/chmod 0755 /run/uwsgi    $BIN --thunder-lock --pidfile $PID --daemonize /var/log/cgit-ui-uwsgi.log --ini $CONFDIR/$CONF.ini  fi}uwsgi_stop() {  echo "Shutdown uWSGI for cGit-ui gracefully..."  /bin/kill -INT $(cat $PID)  /bin/rm -f $PID}uwsgi_reload() {  echo "Reloading uWSGI for cGit-ui configuration..."  kill -HUP $(cat $PID)}uwsgi_restart() {  uwsgi_stop  sleep 3  uwsgi_start}case "$1" in  start)    uwsgi_start    ;;  stop)    uwsgi_stop    ;;  reload)    uwsgi_reload    ;;  restart)    uwsgi_restart    ;;  *)  echo "usage: `basename $0` {start|stop|reload|restart}"esac

Если же необходимо запускать uWSGI-демон во время загрузки системы c BSD-like инициализацией, такой, например, как Slackware, то в файлы /etc/rc.d/rc.M, /etc/rc.d/rc.6 нужно добавить следующие строки:


/etc/rc.d/rc.M:
# Start uWSGI for cGit-ui server:if [ -x /etc/rc.d/rc.cgit-ui-uwsgi ] ; then  /etc/rc.d/rc.cgit-ui-uwsgi startfi

/etc/rc.d/rc.6:
# Stop uWSGI for cGit-ui server:if [ -x /etc/rc.d/rc.cgit-ui-uwsgi ] ; then  /etc/rc.d/rc.cgit-ui-uwsgi stopfi


Nginx


Прежде всего, необходимо включить новый виртуальный сервер в конфигурационный файл Nginx:


/etc/nginx/nginx.conf:
    include /etc/nginx/vhosts/cgit.example.org.conf;


Следующая конфигурация сервера подразумевает использование uWsgi и скрипта cGit-UI на поддомене cgit.example.org:


/etc/nginx/vhosts/cgit.example.org.conf:
## cGit server:#    server {        listen 80;        server_name cgit.example.org;        return 301 https://cgit.example.org$request_uri;    }    server {        listen 443 ssl;        server_name cgit.example.org;        root /var/www/htdocs/cgit;        charset UTF-8;        #        # see:        #   https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security ,        #   https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html        #        # see also: http://classically.me/blogs/how-clear-hsts-settings-major-browsers        # and do not include includeSubdomains; parameter into line:        #        add_header Strict-Transport-Security "max-age=63072000; preload";        error_log /var/log/nginx/cgit.example.org-error.log;        access_log /var/log/nginx/cgit.example.org-access.log;        keepalive_timeout        60;        ssl_certificate          /etc/letsencrypt/live/cgit.example.org/fullchain.pem;        ssl_certificate_key      /etc/letsencrypt/live/cgit.example.org/privkey.pem;        ssl_trusted_certificate  /etc/letsencrypt/live/cgit.example.org/chain.pem;        ssl_protocols            SSLv3 TLSv1 TLSv1.1 TLSv1.2;        ssl_ciphers              "RC4:HIGH:!aNULL:!MD5:!kEDH";        gzip on;        gzip_disable "msie6";        gzip_comp_level 6;        gzip_min_length 1100;        gzip_buffers 16 8k;        gzip_proxied any;        gzip_types text/plain text/css text/js text/xml text/javascript                   image/svg+xml image/gif image/jpeg image/png                   application/json application/x-javascript application/xml application/xml+rss application/javascript                   font/truetype font/opentype application/font-woff application/font-woff2                   application/x-font-ttf application/x-font-opentype application/vnd.ms-fontobject application/font-sfnt;        #        # Serve static content with nginx        #        #        # Rewrite rules for versioning CSS + JS thtouh filemtime directive        #        location ~* ^.+.(css|js)$ {            rewrite ^(.+).(d+).(css|js)$ $1.$3 last;            expires 31536000s;            access_log off;            log_not_found off;            add_header Pragma public;            add_header Cache-Control "max-age=31536000, public";        }        #        # Caching of static files        #        location ~* .(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|ogv|otf|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|t?gz|tif|tiff|ttf|wav|webm|wma|woff|wri|xla|xls|xlsx|xlt|xlw|zip)$ {            expires 31536000s;            access_log off;            log_not_found off;            add_header Pragma public;            add_header Cache-Control "max-age=31536000, public";        }        location ~* ^.+(favicon.ico|robots.txt) {            root /var/www/htdocs/cgit;            expires 30d;        }        location = /robots.txt {            allow all;            log_not_found off;            access_log off;        }        location / {            try_files $uri @cgit-ui;        }        location @cgit-ui {            gzip off;            include uwsgi_params;            uwsgi_modifier1 9;            uwsgi_pass unix:/run/uwsgi/cgit-ui.sock;        }    }


Создание списка репозиториев


Детальные инструкции, описывающие формат файла cgit-ui.rc(5) можно найти на странице руководства:


man 5 cgit-ui.rc


Рабочий Пример


Следующий конфигурационный файл содержит все необходимые, для работы сервера, настройки, одну секцию из списка репозиториев, именуемую Tools и содержащую описание Git-репозитория pkgtools.git.


git-utc-offset = +0300;clone-prefix-readonly = 'git://radix.pro';clone-prefix          = 'git://git@radix.pro:pub';trunk    = 'master';snapshots = 'tar.xz';css = '/.cgit/css/cgit.css';logo = '/.cgit/pixmaps/cgit-banner-280x280.png';logo-alt = "Radix.pro";logo-link = "https://radix.pro";main-menu-logo = '/.cgit/pixmaps/logo/git-logo-white-256x256.svg';favicon-path = '/.cgit/pixmaps/favicon';syntax-highlight-css = '_cgit.css';header = '/.cgit/html/header.html';footer = '/.cgit/html/footer.html';page-size = 200;owner = "Andrey V.Kosteltsev";author = "Andrey V.Kosteltsev";title = "Radix.pro Git Repositories";description = "Git repositories hosted at radix.pro (St.-Petersburg)";keywords = "cGit repositories cgit-ui web web-ui user interface Git";copyright = " Andrey V. Kosteltsev, 2019  2020.";copyright-notice = "Where any material of this site is being reproduced, published or issued to others the reference to the source is obligatory.";home-page = "https://radix.pro/";section "Tools" {  repo 'pkgtools.git' {    owner = "Andrey V.Kosteltsev";    title = "Package Tools Utilities";    description = "Pkgtools  is a set of utilities to create, install, remove and update packages";    home-page = "https://radix.pro/";    git-root = '/u3/scm/git';    clone-prefix-readonly = 'git://git@radix.pro:git';    clone-prefix          = 'git://git@radix.pro:git';  }}


Здесь можно видеть, что cGit-ui CGI-скрипт использует HTML-шаблоны заголовка и подножия страниц, в котрые подставляет значения некоторых переменных, определенных в конфигурационном файле cgit-ui.rc(5).


Такой подход дает возможность пользователю полностью контролировать как внешний вид интерфейса, так и его поведение исходя из собственных предпочтений:


Все необходимые файлы для работы на стороне web-клиента находятся в каталоге /var/www/htdocs/cgit/.cgit/. Редактируя файл /.cgit/html/header.html и меняя значения переменных в файле /etc/cgit-ui.rc, пользователь может сменить favicon.ico, поменять тему подсветки синтаксиса, выбрать изображения для собственных репозиториев, задать ключевые слова для поисковых систем, а также выполнить множество других настроек собственного сервера, представляющего Git-репозиториии.


Внешний вид интерфейса определяется единственным CSS-файлом и поэтому, пользователь может поменять тему web-интерфейса так, как ему будет необходимо.



Дополнительная информация


README, cscmd(8), cgit-ui.rc(5)

Подробнее..

Перевод Вышел релиз GitLab 13.0 с кластерами Gitaly, иерархией эпиков на дорожных картах и автоматическим развертыванием для ECS

15.06.2020 00:20:27 | Автор: admin

Картинка для привлечения внимания


Что изменилось со времени 12.0


Прежде чем приступить к описанию нового мажорного релиза 13.0, мы хотели бы уделить внимание пройденному пути. Мы столького достигли с момента выхода версии 12.0! Недавно в блоге вышел специальный пост, в котором мы сделали обзор релизов GitLab с 12.0 по 12.10. Три наших фаворита из этой серии релизов это управление требованиями, сетевая безопасность контейнеров и конвейеры (в русской локализации GitLab сборочные линии) родитель-ребенок.


В дополнение к улучшениям самого продукта мы также обновили наши партнерские программы и интеграции, добавили рекомендации по интеграции для использования сторонних сканеров безопасности, а также расширили наши пакеты услуг техподдержки, чтобы помочь вам с такими вещами, как миграции Jira и Jenkins. На нашем новом видеоканале Learn@GitLab вы найдете множество видеоуроков. Например, Начало работы с CI.


Итерации ключ к устойчивости


GitLab помогает ИТ- и бизнес-командам развиваться, вовремя реагировать и адаптироваться, и ключ ко всему этому итерации. Пользователям необходимо быстро взаимодействовать, оптимизировать работу и автоматизировать процессы для обеспечения безопасности и соответствия требованиям, не забывая при этом о качестве продукта. GitLab 13.0 поможет вам итерировать быстро и с более глубоким пониманием процесса. Доступ к Git-репозиториям также является критически важным, и мы усовершенствовали наш кластер Gitaly для высокодоступных (HA) хранилищ Git, чтобы в случае сбоя всегда имелось несколько свежих и готовых к работе реплик.


Оперативное реагирование и сотрудничество всей команды


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


Дизайнеры важная часть команды разработчиков. Работая над одной из самых популярных новых фич, темной темой для Web IDE, мы поняли, как привлечь дизайнеров к более тесному сотрудничеству. Также мы переместили управление дизайном в план Core, тем самым отмечая пользователей, которые занимаются дизайном продуктов, как отдельных участников.


Оптимизация для повышения эффективности


Поскольку многие компании стремятся быть более оперативными и более эффективными, GitLab старается упростить существующие процессы разработки программного обеспечения. Новые фичи, направленные на повышение эффективности, включают в себя упрощенное развертывание на Amazon ECS и новый объединенный список оповещений, который объединяет IT-оповещения, поступающие из нескольких источников, в едином интерфейсе. Кроме того, у нас есть хорошая новость и для пользователей Terraform. В GitLab 13.0 появился краткий обзор результата terraform plan в мерж-реквестах (в русской локализации GitLab запросы на слияние) и использование GitLab в качестве бэкенда для state файла.


Доверяйте вашим процессам и не жертвуйте безопасностью и соответствием требованиям


GitLab помогает компаниям комплексно внедрять средства контроля безопасности и соответствия требованиям в жизненный цикл разработки ПО, снижая риски и высвобождая ресурсы для критически важных потребностей бизнеса. Наши возможности тестирования безопасности приложений помогают вам быстрее находить и исправлять уязвимости безопасности, благодаря чему GitLab недавно был назван нишевым игроком в Gartner Magic Quadrant for Application Security Testing 2020 года.


С момента оценки Gartner релиза 12.4 мы добавили много новых фич. А в 13.0 мы добавили возможность сканирования REST API через DAST и полное сканирование истории коммитов на наличие секретных ключей. Более того, мы поменяли наш способ работы с объектами уязвимостей. Благодаря этому появилась возможность экспортировать уязвимости из панели безопасности и в будущем будут доступны более широкие возможности управления уязвимостями.


В дополнение к сканированию безопасности в релизе 13.0 GitLab автоматизирует правила и обеспечивает более детальный контроль с помощью заморозки развертывания с помощью API Freeze Periods. Это поможет легко предотвратить непреднамеренные релизы в продакшн на указанный промежуток времени. Для упрощения аудитов в 13.0 появилась фильтрация в поиске событий аудита на уровне инстанса, это часть нашего эпика по событиям аудита.


А что впереди?


Мы с энтузиазмом готовим предстоящие релизы, в частности, фичи, которые помогут вам:



Хотите увидеть полный список того, что выйдет в следующем месяце? Наша дорожная карта открыта и всегда доступна для всех желающих внести свой вклад.


Теперь, без лишних слов, приступим к описанию всех классных фич релиза 13.0!


Приглашаем на наши встречи.


GitLab MVP badge


MVP этого месяца Sashi


Sashi добавил огромное количество улучшений в релиз 13.0 в различных разделах GitLab. Его работа помогла улучшить контроль версий сниппетов, удалить ошибки, связанные с тегом Releases, и минимизировать дублирование событий, посылаемых веб-хуками. Также он улучшил структуру и читаемость кода, обеспечив каждому формату пакета уникальную модель для хранения метаданных.


Спасибо Sashi за всю эту работу!


Ключевые фичи релиза GitLab 13.0


Кластер Gitaly для высокодоступных хранилищ Git


(PREMIUM, ULTIMATE) Стадия цикла DevOps: Create


GitLab теперь поддерживает высокодоступные системы хранения Git без использования NFS. Конфигурации высокой доступности (high availability, HA) повышают доступность важных систем, таких как хранилища Git, за счет устранения единичных точек отказа, обнаружения сбоев и автоматического переключения на реплику. Это означает, что отдельный компонент системы может выйти из строя, не вызвав сбоя у конечного пользователя. Доступ к репозиториям Git очень важен для разработчиков и компаний, поскольку при его выходе из строя разработчики не смогут отправлять код и развертывание будет заблокировано.


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


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


Gitaly Cluster for high availability Git storage


Документация по Praefect и оригинальный эпик.


Автоматическое развертывание в ECS


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


До сих пор у нас не было простого способа развертывания в Amazon Web Services. Из-за этого пользователям GitLab приходилось тратить много времени на настройку собственной конфигурации.


В GitLab 13.0 поддержка развертывания в AWS уже ждет вас в Auto DevOps! Пользователи GitLab, которые развертывают в Elastic Container Service (ECS) от AWS, теперь могут воспользоваться возможностями Auto DevOps, даже если они не используют Kubernetes. Auto DevOps упрощает и ускоряет поставку и облачное развертывание с помощью полного конвейера поставки сразу из коробки. Благодаря устранению лишних сложностей вы сможете сконцентрироваться на аспектах создания программного обеспечения. Просто отправьте коммит, а GitLab сделает все остальное!


Чтобы подключить эту фичу, необходимо определить переменные окружения для AWS: AWS_ACCESS_KEY_ID, AWS_ACCOUNT_ID и AWS_REGION, а также включить Auto DevOps. Затем ваше развертывание ECS будет автоматически собрано для вас с полным автоматическим конвейером поставки.



Документация по развертыванию в ECS и оригинальный тикет.


Просмотр иерархии эпиков на дорожной карте


(ULTIMATE, GOLD) Стадия цикла DevOps: Plan


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


View Epic hierarchy on a Roadmap


Документация по дорожным картам и оригинальный тикет.


Контроль версий для сниппетов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


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


Теперь сниппеты в GitLab также находятся под контролем версий в Git-репозитории. При редактировании сниппета каждое изменение создает коммит. Сниппеты также можно клонировать для локального редактирования, а затем отправлять в репозиторий Snippet.


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


Versioned Snippets


Документация по контролю версий в сниппетах и оригинальный тикет.


Темная тема в Web IDE


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


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


Web IDE теперь полностью темная для всех пользователей, выбравших Dark в настройках темы подсветки синтаксиса. Это важный шаг в обеспечении удобства редактирования и в понимании того, как пользовательский интерфейс GitLab взаимодействует с темными темами. Вы можете узнать больше о разработке этого дизайна в соответствующем посте.


Dark Theme in the Web IDE


Документация о темах в Web IDE и оригинальный тикет.


Отдельные объекты уязвимостей


(ULTIMATE, GOLD) Стадия цикла DevOps: Defend


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


Одно из самых больших преимуществ заключается в том, что теперь каждая уязвимость будет иметь уникальный URL. Это означает, что на уязвимость можно ссылаться напрямую, делиться ей и отслеживать ее как единый источник информации. На этой странице вы можете изменить статус уязвимости на Обнаружена ("Detected"), Подтверждена ("Confirmed"), Проигнорирована ("Dismissed") или Решена ("Resolved"). Еще одним преимуществом является то, что обнаруженные уязвимости будут сохраняться при следующем запуске сканера. Ранее запуск сканирования на той же ветке перезаписывал все предыдущие результаты новыми. Сохранение прошлых объектов уязвимостей улучшит качество отслеживания, наглядность и сократит дублирование результатов между прогонами сканера. Кроме того, это даст в будущем возможность создавать отчеты о тенденциях уязвимостей в группах и проектах с течением времени по широкому ряду параметров.


Standalone Vulnerability Objects


Документация по уязвимостям и оригинальный тикет.


Поддержка REST API в сканированиях DAST


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


В GitLab 13.0 мы добавили DAST сканирования REST API. Это позволит обеспечить полное DAST-покрытие безопасности всего приложения, а не только пользовательского интерфейса. DAST поддерживает использование спецификации OpenAPI в качестве руководства по сканированию URL-адресов и конечных точек REST, что позволит обеспечить безопасность всех направлений атак и даст больше информации о потенциальных уязвимостях любого работающего приложения.



Документация по DAST-сканированию API и оригинальный тикет.


SAST для .NET Framework


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


Мы представляем начальную поддержку .Net Framework, которая позволит разработчикам запускать сканирования безопасности SAST в дополнительных типах .NET проектов. Как и в других наших заданиях SAST, в них будут использоваться обработчики заданий GitLab (runner) для Linux. В будущем мы планируем добавить поддержку обработчиков заданий Windows. С момента появления в GitLab 11.0, SAST для .NET включал в себя поддержку только для проектов .NET Core.


Поддерживаемый язык Инструмент сканирования Представлен в версии GitLab
.NET Core Сканирование безопасности кода 11.0
.Net Framework Сканирование безопасности кода 13.0

SAST for .NET Framework


Документация по поддерживаемым SAST языкам и оригинальный тикет.


Краткий обзор результата terraform plan в мерж-реквестах


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure


Если вы используете Terraform для определения вашей инфраструктуры в виде кода, вы знаете, как удручает необходимость постоянно передавать коллегам итоговые изменения из команды terraform plan в slack и комментариях в мерж-реквестах. В GitLab 13.0 теперь вы будете видеть краткий обзор вывода команды terraform plan в том контексте, где это наиболее полезно непосредственно в вашем мерж-реквесте. Это поможет вам быстрее проверять изменения в вашей инфраструктуре и предоставит удобное место для взаимодействия с членами вашей команды по предполагаемому влиянию на вашу инфраструктуру по мере изменения кода.


Пользователи шаблона Terraform, предлагаемого GitLab, увидят виджет мерж-реквеста terraform plan без какой-либо дополнительной настройки. Пользователи персонализированных шаблонов CI/CD могут обновить свой шаблон, чтобы использовать образ и скрипты официального шаблона Terraform от GitLab.


Review summary of `terraform plan` in Merge Requests


Документация по работе с инфраструктурой с помощью Terraform и оригинальный эпик.


Использование GitLab в качестве бэкенда для state файла Terraform


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure


Пользователи Terraform прекрасно знакомы с трудностями настройки state файла (карта связей вашей конфигурации с реальными ресурсами, в которой также отслеживаются дополнительные метаданные). Этот процесс включает в себя создание нового проекта Terraform и настройку стороннего бэкенда для хранения надежного, безопасного и не зависящего от вашего git-репозитория файла состояния.


Многие пользователи искали более простой способ настройки файлового хранилища без использования дополнительных сервисов или настроек. Начиная с GitLab 13.0 как HTTP-бэкенд для Terraform можно использовать сам GitLab, что устраняет необходимость настраивать отдельное хранилище для state файлов для каждого нового проекта.


Бэкенд состояний Terraform от GitLab обеспечивает простоту настройки и возможность хранить ваши state файлы в месте, контролируемом инстансом GitLab. Доступ к ним можно получить с помощью специального HTTP-бэкенда, используя GitLab для аутентификации. Пользователи смогут легко мигрировать на HTTP-бэкенд Terraform от GitLab, а также получить к нему доступ со своих локальных терминалов.


HTTP-бэкенд для состояний Terraform от GitLab поддерживает:


  • Многочисленные именованные файлы состояния в одном проекте
  • Блокировку
  • Хранилище объектов
  • Шифрование в состоянии покоя

Все это теперь доступно и для пользовательских инстансов GitLab, и на GitLab.com.


GitLab HTTP Terraform state backend


Документация по работе с инфраструктурой с помощью Terraform и оригинальный эпик.


Исключайте большие файлы с помощью частичного клонирования


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Хранение больших бинарных файлов в Git обычно не приветствуется, поскольку все добавленные файлы будут загружены каждым, кто впоследствии клонирует или проверяет обновления (git fetch) репозитория. Это сильно замедляет, если вовсе не останавливает, работу при медленном или ненадежном соединении.


В GitLab 13.0 частичное клонирование было включено для фильтров по размеру блоба, а также экспериментально для других фильтров. Это позволяет исключить проблемные большие файлы из клонирований и скачиваний обновлений. Когда Git обнаруживает недостающий файл, он будет загружен по требованию. При клонировании проекта используйте --filter=blob:none для полного исключения блобов или --filer=blob:limit=1m для исключения по размеру файла. Обратите внимание, что для частичного клонирования требуется версия Git не ниже 2.22.0.


Узнайте все подробности в нашем недавнем посте Как частичное клонирование в Git позволяет вам получать только необходимые большие файлы.


Exclude large files using Partial Clone


Документация по частичному клонированию и оригинальный тикет.


Управление панелями метрик через переменные


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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



Документация по шаблонам переменных для панелей метрик и оригинальный эпик.


Сниженное потребление памяти GitLab с Puma


(CORE, STARTER, PREMIUM, ULTIMATE) Доступность


Puma теперь по умолчанию является сервером веб-приложений для установок на основе Omnibus и Helm. Puma снижает объем памяти, потребляемой GitLab, примерно на 40% по сравнению с Unicorn, что повышает эффективность работы GitLab и позволяет потенциально сэкономить на стоимости инстансов с самостоятельным управлением.


Установкам, которые настроили количество процессов Unicorn, или используют более медленные диски с NFS, возможно придется изменить конфигурацию Puma по умолчанию. Посмотрите важные заметки по обновлениям и улучшения в GitLab chart, чтобы узнать больше.


Reduced memory consumption of GitLab with Puma


Документация по Puma и оригинальный эпик.


Другие улучшения в GitLab 13.0


Фильтр для поиска по событиям аудита в инстансе


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


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


Filtered search for instance-level audit events


Документация по событиям аудита и оригинальный тикет.


Включение защиты веток по умолчанию на уровне группы


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


Раньше при переносе настроек защиты ветки по умолчанию с уровня инстанса на уровень проектов можно было легко запутаться, потому что в некоторых сценариях этот процесс был неинтуитивным: разработчики не могли добавлять новые коммиты в проекты, которые они же и создали. Из-за этого организациям было сложно найти баланс между снижением рисков и предоставлением свободного доступа к проектам для всех разработчиков, так как решение проблемы требовало повышения их до maintainer (в русской локализации GitLab сопровождающий).


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


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


Документация по настройке защиты веток по умолчанию на уровне группы и оригинальный тикет.


Аналитика цикла разработки: график задач по типу


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


Value Stream Analytics | Tasks by Type


Документация по графику задач по типу работы и оригинальный тикет.


Email-уведомления при авторизации из неизвестного источника


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


Документация по уведомлениям при авторизации из неизвестных источников и оригинальный тикет.


Предупреждение при закрытии тикета с неразрешенными зависимостями


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan


В GitLab 12.8 мы добавили возможность создавать зависимости между тикетами, так что один тикет может блокировать другой. Это означает, что зависимый тикет не может быть закрыт, пока не будет завершен и закрыт главный. Из-за этого вам приходилось перед закрытием тикета проверять, не является ли он заблокированным другими.


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


Эти уведомления о зависимостях позволят вашим проектам работать без заминок, а также обеспечат правильную последовательность тикетов.


Документация по зависимостям между тикетам и оригинальный тикет.


Более удобное добавление эпиков и тикетов через дерево эпиков


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Plan


Создание и добавление тикетов и эпиков через дерево эпиков ранее было разделено по нескольким кнопкам и выпадающим меню, и поэтому его было неудобно использовать. Мы объединили действия add (добавить) и create (создать) в отдельную кнопку с меню, чтобы добавлять новые тикеты и эпики было проще и быстрее!


Add Epics or issues via the Epic Tree more easily


Документация по добавлению тикетов в эпик и оригинальный тикет.


Эмодзи в обсуждении дизайнов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


В версии 13.0 обсуждения дизайнов стали на шаг ближе к комментариям в GitLab. Мы добавили поддержку эмодзи, чтобы вы могли давать обратную связь более веселым и креативным способом!


Use emojis in design comments to enhance feedback


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


Новый режим сравнения для мерж-реквестов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Мерж-реквесты, особенно вкладка Изменения (Changes), это место, где происходит обсуждение и ревью исходного кода. В случаях, когда целевая ветка была смержена в исходную ветку мерж-реквеста, изменения в исходной и целевой ветках могут оказаться перемешанными, из-за чего становится сложно понять, какие изменения добавляются, а какие уже существуют в целевой ветке.


В GitLab 13.0 мы добавляем экспериментальный режим сравнения. Он будет показывать дифф, рассчитанный путем симуляции мержа, что даст более точное представление изменений, чем использование мержей обеих веток. Этот режим доступен в выпадающем меню ветки, выбранной для сравнения через пункт master (HEAD). В будущем этот режим заменит текущий способ сравнения по умолчанию.


Документация по режиму сравнения для мерж-реквестов и оригинальный тикет.


Темы подсветки синтаксиса для Web IDE


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


GitLab поддерживает шесть тем подсветки синтаксиса при просмотре кода. Темы крайне важны для удобства разработчиков при просмотре и редактировании кода в GitLab. Теперь мы добавили поддержку всех шести тем подсветки синтаксиса в Web IDE, включая Solarized Dark, Solarized Light, Monokai и режим без подсветки.


На протяжении нескольких последних релизов (например, в 12.8 и 12.9) мы добавляли и улучшали поддержку тем подсветки в Web IDE. Новые темы подсветки являются продолжением этой работы и помогли заложить основу для нашей темной темы в Web IDE, которая также выходит в 13.0. Мы продолжаем улучшать интерфейс для разработчиков и делать нашу Web IDE более комфортной.


Syntax Highlighting Themes for the Web IDE


Документация по темам Web IDE и оригинальный эпик.


Подсветка пинов комментариев к дизайну для удобного обсуждения


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Когда над одним дизайном ведется много обсуждений, становится сложно определить, какие обсуждения относятся к какому пину, без поиска номера этого комментария.


В релизе 13.0 мы добавили механизм подсветки пинов релевантных комментариев при клике на исходный комментарий. Мы также добавили обратную фичу, чтобы вы могли кликнуть на пин и перейти к исходному комментарию. Это позволит не тратить время на то, чтобы вручную листать комментарии в поисках нужного, когда под дизайном много комментариев.


Visually highlight design comment pins so you can follow the discussion


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


Правила пушей для групп


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


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


Документация по правилам пушей для групп и оригинальный тикет.


Кнопки навигации по коммитам в мерж-реквестах


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Удобная навигация по коммитам в больших мерж-реквестах позволяет более эффективно проводить ревью с перемещением между коммитами.


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


Commit navigation buttons in merge requests


Документация о навигации по коммитам мерж-реквеста и оригинальный тикет.


Доступ к отчетам JUnit через API GitLab


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Отчет JUnit может содержать информацию для обновления планов тестирования, истории выполнения тестов и других артефактов, которые команды используют, чтобы следить за качеством своего кода. Обновление этих артефактов может быть долгим и утомительным процессом. Что еще хуже, отчеты были JUnit доступны только путем скачивания через пользовательский интерфейс GitLab. Начиная с версии GitLab 13.0 пользователи API GitLab смогут получать доступ к отчетам JUnit напрямую. Это позволит пользователям парсить данные JUnit для создания новых тикетов или обновления истории выполнения тестов.


Документация по отчетам о выполнении тестов на конвейере и оригинальный тикет.


Фильтр для конвейеров по автору триггера и названию ветки


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Поиск конвейеров, запущенных определенным пользователем или на определенной ветке, стал проще, чем когда-либо. С новым фильтром на странице конвейеров вы сможете фильтровать коммиты по автору коммита и/или по названию ветки. Настройка страницы конвейеров при помощи этих фильтров позволит вам получать актуальную информацию об активности тех конвейеров, которые наиболее важны для вас.



Документация по странице конвейеров и оригинальный тикет.


Доступ к реестру пакетов GitLab для чтения или записи через токены развертывания


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package


Токены развертывания позволяют вам получать доступ к репозиториям группы, репозиториям проекта и реестрам контейнеров. Команды read_repository, read_registry и write_registry ранее не позволяли вам получать доступ к реестру пакетов GitLab. В результате командам DevOps приходилось использовать небезопасные или дорогостоящие обходные пути.


В GitLab 13.0 мы добавили более точные настройки разрешений токенов развертывания GitLab. Теперь вы можете задавать доступ к реестру пакетов для чтения или записи. Создавать токены развертывания и управлять ими можно из приложения GitLab или через API.


Документация по токенам развертывания и оригинальный тикет.


Все версии пакета под одним именем


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package


Реестр пакетов GitLab ранее рассматривал каждую новую версию пакета как новый пакет. Из-за этого было сложно искать нужные пакеты или сравнивать изменения между разными версиями пакета.


В GitLab 13.0 каждая версия пакета будет находиться под родительским пакетом с уникальным именем. Это упростит поиск нужного пакета через пользовательский интерфейс и просмотр изменений между версиями. Это обновление применяется для уровней групп и проектов в реестре пакетов. Кроме того, при использовании API пакетов версии пакета будут возвращаться как массив под именем родительского пакета.


Package versions are now nested under their parents


Документация по получению пакета проекта и оригинальный тикет.


Заморозка развертывания через API Freeze Period


(ULTIMATE, GOLD) Стадия цикла DevOps: Release


С этим релизом GitLab предоставляет больше способов управлять окружениями. Новый API Freeze Period позволит вам легко предотвратить непреднамеренный релиз в продакшн в течение заданного вами периода, например, во время праздника или корпоративного события. Теперь вы можете пользоваться правилами, которые обычно находятся за пределами GitLab, чтобы уменьшить неопределенность и риск при автоматизации развертываний.


Документация по замораживанию развертываний и оригинальный тикет.


Обновление майлстоунов релиза через пользовательский интерфейс GitLab


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


Команда управления разделом Релизов GitLab работает над расширением страницы релиза для использования всей функциональности API релизов. В версии 13.0 стало проще добавлять один или несколько майлстоунов к вашим релизам. С этим обновлением вам больше не придется вручную вызывать API релизов, чтобы пользоваться фичами для планирования, такими как просмотр прогресса по релизу, который был представлен в версии 12.9.


Update Release's milestone in Web UI


Документация по редактированию релиза и оригинальный тикет.


Поиск образов по имени в реестре контейнеров GitLab


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package


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


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


Документация по управлению реестром контейнеров через GitLab и оригинальный тикет.


Просмотр нагрузки и аннотаций внешних IT-уведомлений в GitLab


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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


Документация по странице уведомлений и оригинальный тикет.


Рендер эмодзи на странице состояния проекта


(ULTIMATE, GOLD) Стадия цикла DevOps: Monitor


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


Документация по странице информации по инциденту и оригинальный тикет.


Переключение видимости панели метрик


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


Ранее администраторы проекта не могли управлять разрешениями на просмотр панели метрик проекта. В GitLab 13.0 администраторы смогут разрешать видимость панели метрик либо только участникам проекта, либо всем пользователям с правами доступа.


Toggle Metrics Dashboards visibility


Документация по видимости панели метрик и оригинальный тикет.


Добавление аннотаций на панель метрик


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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


Add annotations to a Metrics Dashboard


Документация по аннотациям на панелях метрик Prometheus и оригинальный эпик.


Поиск секретных ключей в полной истории репозитория


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


В GitLab 13.0 мы обновляем наше сканирование для поиска секретных ключей для поддержки новой переменной SAST_GITLEAKS_HISTORIC_SCAN, что позволит проводить сканирование полной истории репозитория. Это поможет вам находить ключи, которые могли затеряться среди старых коммитов. На момент появления в GitLab 11.9 сканирование для поиска секретных ключей проводилось по истории изменений в коммитах мерж-реквеста, что позволяло находить новые добавленные ключи, но не затрагивало более давнюю историю коммитов. Наша новая фича будет особенно полезна при использовании поиска секретных ключей в репозитории в первый раз для полного сканирования репозитория на наличие ключей.


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



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


Экспорт списка уязвимостей из панелей безопасности инстанса и проекта


(ULTIMATE, GOLD) Стадия цикла DevOps: Defend


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


Теперь вы можете загружать файл в формате CSV со всеми обнаруженными уязвимостями для определенного проекта или для всех проектов, управляемых на панели безопасности инстанса. Этот список можно использовать для создания отчетов по безопасности или как источник данных для внешних панелей безопасности. Просто перейдите к панели безопасности инстанса или к панели безопасности любого проекта и нажмите новую кнопку Export справа вверху или выберите Security в меню More на верхней панели навигации, затем нажмите новую кнопку Export в правом верхнем углу. Ваш браузер автоматически начнет загрузку.


Export vulnerabilities list from Instance and Project Security Dashboards


Документация по экспорту уязвимостей и оригинальный тикет.


Интеграция SIEM с файерволом веб-приложений


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Defend


Мы объявляем о новой интеграции SIEM для файервола веб-приложений (WAF). Эта интеграция позволяет пользователям экспортировать свои логи WAF в SIEM или в централизованное решение для логирования, чтобы можно было просматривать любые аномалии, обнаруженные WAF. Эта фича также облегчает пользователям тестирование и настройку пользовательских правил WAF, что уменьшает количество ложных срабатываний. Интеграцию SIEM можно настроить, включив Fluentd на странице Операции > Kubernetes (Operations > Kubernetes).


Web Application Firewall (WAF) SIEM Integration


Документация по Fluentd и оригинальный тикет.


Вторичные ноды Geo автоматически пересылают запросы SSH для несинхронизированных репозиториев


(PREMIUM, ULTIMATE) Доступность


Geo поддерживает выборочную синхронизацию проектов, что позволяет системным администраторам выбирать подмножество данных, реплицируемое во вторичные ноды Geo. Geo уже поддерживает перенаправление запросов HTTP(S) на основной сервер при попытке доступа к этим несинхронизированным репозиториям. Однако пользователи, пытавщиеся получить доступ к несинхронизированным репозиториям на вторичной ноде через SSH, получали сообщение об ошибке, что репозиторий недоступен. Это сбивало с толку пользователей и заставляло их либо ждать синхронизации хранилища, либо выполнять дополнительную работу для подключения к нужному хранилищу.


В GitLab 13.0 любые запросы Git, сделанные через SSH к несинхронизированной вторичной ноде Geo, будут перенаправлены на первичную ноду. Это приводит к гораздо более плавному взаимодействию с пользователями, поскольку им не нужно будет знать, что реплицируется или не реплицируется на эту ноду: Geo выполнит запрос как по HTTP(S), так и по SSH без какой-либо дополнительной настройки.


Документация по настройке операций Git с нереплицированными репозиториеями и оригинальный эпик.


Обработчик заданий теперь поддерживает загрузку артефактов непосредственно из хранилища объектов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Обработчик заданий GitLab (GitLab Runner) 13.0 теперь поддерживает загрузку артефактов непосредственно из хранилища объектов. Когда эта опция включена, сервер GitLab будет перенаправлять обработчик заданий непосредственно в хранилище объектов, а не проксировать трафик. Это может привести к значительной экономии затрат на передачу по сети, а также к снижению нагрузки на сервер GitLab.


Для подключения установите переключаемую фичу FF_USE_DIRECT_DOWNLOAD в true через переменную окружения.


Документация по доступным переключаемым фичам и оригинальный тикет.


Добавлены события аудита для действий администратора под именем пользователя


(PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage


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


Это важное дополнение к событиям аудита исправляет пробел в неоспоримости действий (nonrepudiation) для вашей программы соответствия требованиям и повышает надежность и полноту данных о событиях аудита GitLab.


Документация по событиям аудита и оригинальный тикет.


Аналитика цикла разработки: метрики для времени выполнения и времени цикла


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


Value Stream Analytics | Lead time, cycle time metrics


Документация по аналитике цикла разработки и оригинальный тикет.


Приложение интеграции Okta SCIM для GitLab.com


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage


Теперь мы предлагаем приложение интеграции Okta SCIM для групп на Gitlab.com. Когда Okta SCIM настраивается для группы GitLab, членство в этой группе синхронизируется между GitLab и Okta. Это экономит время администратора группы, затрачиваемое на добавление и удаление пользователей.


Документация по настройке SCIM и оригинальный эпик.


Экспорт и импорт групп в пользовательском интерфейсе


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


Ранее пользователи могли переносить группы только с помощью API экспорта и импорта: сначала требовалось создать файл экспорта, а затем снова с помощью API загрузить файл в нужный инстанс.


В качестве первого шага на пути к более удобному решению мы включили экспорт группы в пользовательском интерфейсе GitLab. Мы планируем добавить аналогичную функциональность для импорта в пользовательский интерфейс в течение нескольких следующих недель.


Документация по импорту и экспорту и оригинальный эпик.


Просмотр майлстоунов на дорожной карте


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Plan


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


View Milestones on the Roadmap


Документация по дорожным картам и оригинальный тикет.


Перетаскивание тикетов между эпиками в дереве эпиков


(ULTIMATE, GOLD) Стадия цикла DevOps: Plan


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


Assign an issue to a different Epic via drag and drop in the Epic Tree


Документация по управлению эпиками и оригинальный тикет.


Управление дизайнами теперь в Core


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


В релизе 12.2 управление дизайнами началось с загрузки дизайнов и обсуждения интересующих мест в рамках GitLab Premium. С тех пор мы рассматривали как отдельных участников наших пользователей, занимающихся дизайном продуктов, а в 13.0 мы переместили эти две фичи в GitLab Core. Это согласуется с нашей моделью покупки для индивидуальных разработчиков. Мы ожидаем, что в будущем по мере развития управления дизайнами мы добавим другие замечательные командные функции, такие как согласование.


Так что теперь все пользователи могут загружать дизайны и давать обратную связь по дизайну в тикетах GitLab. Напоминаем, что вы найдете вкладку Дизайн (Design) рядом с вкладкой Обсуждение (Discussion) в любом тикете. Для начала попробуйте загрузить скриншот с помощью перетаскивания.


Design Management moved to Core


Документация по управлению дизайнами и оригинальный тикет.


Улучшенный редактор сниппетов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


С выпуском сниппетов с поддержкой версий в GitLab 13.0 мы обновили редактор сниппетов до более легкой версии редактора из нашей Web IDE. С помощью этого редактора пользователи смогут воспользоваться базовым дополнением кода и статическим анализом (линтингом) для некоторых языков. Мы также улучшили определение языка исходного кода для лучшей подсветки синтаксиса и добавили поддержку для всех наших тем подсветки синтаксиса. Эти улучшения облегчат редактирование и совместную работу над сниппетами.


Мы рады обеспечить согласованность редактора сниппетов и редактора в Web IDE. В следующем релизе мы добавим эти возможности также для нашего редактора одиночного файла и редактирования файла .gitlab-ci.yml.


Improved Snippets editor


Документация по сниппетам и оригинальный тикет.


WYSIWYG для редактора статических сайтов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Markdown это мощный и эффективный синтаксис для создания веб-контента. Но даже опытные авторы контента в Markdown могут подзабыть некоторые из редко используемых параметров форматирования или с трудом пишут даже умеренно сложные таблицы с нуля. Некоторые работы удобнее выполнять с помощью визуального редактора что видите, то и получите (WYSIWYG).


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


WYSIWYG for the Static Site Editor


Документация по редактору статических сайтов и оригинальный тикет.


Фильтр Approved-by для мерж-реквестов


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Create


Утверждение мерж-реквеста требует, чтобы определенные люди одобрили изменения, прежде чем их можно будет смержить. При поиске в списке мерж-реквестов вы можете быстро найти, какие из них нуждаются в вашем одобрении, с помощью фильтра Утверждающие (Approvers). В GitLab 13.0 теперь вы также сможете найти любые ранее одобренные вами мерж-реквесты, используя новый фильтр Approved-By.


Approved-by filter for merge requests


Документация по фильтрации мерж-реквестов и оригинальный тикет.


Поддержка родительских групп и пользователей в файле CODEOWNERS


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


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


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


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


Документация по определению владельцев кода и оригинальный тикет.


Наследование переменных окружения от других заданий


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Теперь можно передавать переменные окружения и другие данные между заданиями CI. Используя ключевое слово dependencies (или ключевое слово needs для конвейеров DAG), задание может наследовать переменные от других заданий, если они получены с помощью артефактов отчета dotenv. Это предлагает более изящный подход для обновления переменных между заданиями по сравнению с использованием артефактов или передачей файлов.


Документация по наследованию переменных окружения и оригинальный тикет.


Настраиваемый порог тестирования производительности браузера


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Verify


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


Документация по настройке показа отчета о производительности и оригинальный тикет.


Просмотр более надежных данных в списке в пользовательском интерфейсе реестра пакетов


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package


До этого релиза в списочном представлении реестра пакетов отображался ограниченный объем информации, относящейся к пакетам. Хотя эта информация важна, в ней отсутствовали ключевые метаданные, такие как версия, ветка и коммит.


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


View more robust data in the list view Package Registry user interface


Документация по просмотру дополнительной информации о пакете и оригинальный тикет.


Просмотр всех ваших пакетов Python в одном месте с помощью реестра пакетов GitLab


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package


Пользовательский интерфейс реестра пакетов GitLab позволяет вам подтвердить, что ваши пакеты были собраны правильно, и устранить неполадки, если что-то пошло не так. Однако MVC нового репозитория PyPI, запущенного в 12.10, не включал эту функциональность.


В версии 13.0 мы добавили репозиторий PyPI в пользовательский интерфейс реестра пакетов. Теперь вы можете просматривать и загружать пакеты PyPI вашего проекта или группы и проверять метаданные и правильность сборки пакета. Вы также можете скопировать команды настройки и установки для более эффективного совместного использования и разработки. Если пакет был собран с использованием конвейера GitLab, вы сможете просмотреть и связать его с конвейером, а также с коммитом, который использовался для публикации пакета.


View all of your Python packages in one place with the GitLab Package Registry


Документация по репозиторию PyPI и оригинальный тикет.


Поддержка API для списков переключаемых фич


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release


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


Документация по спискам переключаемых фич и оригинальный тикет.


Определите правила, чтобы важные образы никогда не удалялись


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package


Ранее при использовании правила истечения срока действия образов в GitLab невозможно было выразить что-то вроде несмотря ни на что, не удалять этот тег. Это вносит риск в процесс удаления, поскольку могут быть удалены образы release или master, которые должны сохраняться.


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


Define policies to ensure important images are never deleted


Документация по правилам истечения срока действия и оригинальный тикет.


Используйте облачные пакеты сборки для Auto DevOps (бета-версия)


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure


Облачные пакеты сборки являются следующей итерацией пакетов сборки. В то время как GitLab в настоящее время по умолчанию использует пакеты сборки Herokuish, мы намерены перевести Auto DevOps на облачные пакеты сборки, когда проект созреет, чтобы предоставить нашим пользователям надежное и хорошо поддерживаемое решение. В этом релизе вы можете выбрать использование бета-версии облачных нативных пакетов сборки в конвейерах Auto DevOps, установив переменную CI AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED.


Документация по облачным пакетам сборки для Auto DevOps и оригинальный тикет.


Агрегирование оповещений из внешних инструментов в GitLab


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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


Документация по списку оповещений и оригинальный тикет.


Добавьте часто используемые панели мониторинга в избранное


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


В GitLab 13.0 вы сможете добавлять свои часто используемые панели мониторинга в избранное, нажимая кнопку Star. Отмеченная звездочкой панель отображается в начале результатов поиска, что экономит ваше время.


Add frequently used dashboards to favorites


Документация по добавлению панелей мониторинга в избранное и оригинальный эпик.


Отображение графиков в полноэкранном режиме


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


В GitLab 13.0 теперь можно отображать графики метрик в полноэкранном режиме, что позволяет более подробно рассмотреть информацию на них при сортировке инцидентов.



Документация по разворачиванию панели Prometheus и оригинальный эпик.


Анонимизация на страницах статуса


(ULTIMATE, GOLD) Стадия цикла DevOps: Monitor


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


Документация по публикации инцидентов и оригинальный тикет.


Просмотр списка просканированных DAST ресурсов


ULTIMATE, GOLD) Стадия цикла DevOps: Secure


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


GitLab 13.0 предоставляет полный список ресурсов, которые были просканированы DAST. Теперь вы можете оценить DAST-сканирование, чтобы убедиться, что приложение защищено со всех сторон. Для упрощения дальнейшего анализа можно загрузить списки сканирования непосредственно с экрана результатов.


Документация по списку просканированных объектов и оригинальный тикет.


Интеграции SIEM для правил контейнерных сетей


(ULTIMATE, GOLD) Стадия цикла DevOps: Defend


Мы представляем новую интеграцию SIEM для правил сетевой безопасности контейнеров. Интеграция позволяет пользователям экспортировать свои логи Cilium в SIEM или в централизованное решение для логирования, чтобы они могли просматривать любые аномалии, обнаруженные их сетевыми правилами. Просмотр журналов также помогает пользователям тестировать и настраивать свои сетевые правила, чтобы снизить вероятность ложных срабатываний. Интеграцию SIEM можно настроить на странице Операции > Kubernetes (Operations > Kubernetes).


Container Network Policies SIEM Integration


Документация по Fluentd и оригинальный тикет.


Оперативная информация о базе данных уязвимостей


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


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


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


Документация по базе данных уязвимостей и оригинальный тикет.


PostgreSQL 11 теперь минимально необходимая версия для установки GitLab


(CORE, STARTER, PREMIUM, ULTIMATE) Доступность


Теперь минимальной требуемой версией PostgreSQL для всех пользовательских инстансов стала PostgreSQL 11. PostgreSQL версий 9.6 и 10 были удалены в GitLab 13.0. Это обновление позволяет нам начать вводить улучшения производительности на основе функций разбиения на разделы, которые были добавлены в PostgreSQL 11. Мы планируем поддерживать PostgreSQL 11 на протяжении всей серии релизов GitLab 13.x. Поддержка PostgreSQL 12 будет добавлена в ближайшее время. Посмотрите важные замечания по обновлению для получения инструкций по обновлению PostgreSQL.


Документация по настройке баз данных и оригинальный эпик.


Улучшена производительность репликации Geo для артефактов заданий, загрузок и файлов LFS


(PREMIUM, ULTIMATE) Доступность


Чтобы определить, что нужно реплицировать с первичной базы данных, Geo сравнивает базу данных отслеживания с вторичной базой данных только для чтения. Если запросы к базе данных Geo выполняются слишком долго, то данные не могут быть успешно реплицированы. В GitLab 13.0 мы используем новый подход к синхронизации артефактов заданий и загрузок, тем самым исключая возможность таймаутов базы данных. Мы также улучшили производительность запросов к базе данных для извлечения артефактов заданий, объектов LFS и загрузок, когда эти файлы хранятся локально. Это повышает общую масштабируемость и производительность GitLab Geo.


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


Документация по репликации Geo и оригинальный эпик.




Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 13.0 released with Gitaly Clusters, Epic Hierarchy on Roadmaps, and Auto Deploy to ECS.


Над переводом с английского работали cattidourden, maryartkey, ainoneko и rishavant.

Подробнее..

Перевод Вышел GitLab 13.1 с управлением оповещениями, качеством кода и улучшениями для безопасности и соответствия требованиям

10.07.2020 14:07:02 | Автор: admin

Картинка для привлечения внимания


Релиз GitLab 13.1 уже доступен! Улучшения нового релиза включают расширенное управление уведомлениями и инструменты, которые помогут вам контролировать и улучшать качество кода, а также другие способы поддержания безопасности и соответствия вашего кода требованиям.


Автоматизируйте и расширяйте управление оповещениями


Оповещения необходимы для обслуживания приложения, но изучение и сортировка всех выдаваемых оповещений могут значительно снизить производительность и время отклика. Система управления оповещениями в GitLab объединяет и упорядочивает оповещения всех ваших сервисов, упрощая их анализ и устранение, повышая производительность и помогая вам сразу же приступить к изучению и ликвидации критических проблем. Ключевые нововведения в 13.1 включают назначение оповещений, интеграцию Slack и создание GitLab To-Dos при назначении оповещений.


Улучшение качества кода


Скорость развертывания имеет значение только в том случае, если вы развертываете качественный код. Благодаря приоритизации тестов для недавно измененного кода разработчики смогут сразу же начать устранять ошибки, не выполняя при этом весь набор тестов. Отслеживание покрытия кода с течением времени позволяет выявить тенденции качества как для разработчиков, так и для менеджеров, а встроенный code intelligence увеличивает скорость и точность ревью кода, интегрируя справочные материалы непосредственно в GitLab.


Укрепление и повышение уровня безопасности и соответствия требованиям


Безопасность важна для всех, и мы стремимся сократить барьеры на пути к полностью безопасному и совместимому SDLC. Вот почему мы рады сообщить, что мы перевели SAST-сканирование Brakeman в план Core, предоставляя возможность сканировать исходный код на наличие известных уязвимостей каждому Rails разработчику, независимо от уровня плана. Для организаций, ориентированных на соблюдение требований, мы добавили пользовательский интерфейс управления правилами для сетевых правил контейнеров, а также включили экспорт уязвимостей на уровне группы в CSV-файл для аудита или дальнейшего внутреннего анализа. Кроме того, мы внесли пару UX-улучшений в панель безопасности, добавив сохранение фильтров и иконки состояния тикетов для поддержания контекста во время работы в этой панели.


И это еще не все!


Это лишь небольшая выборка из обновлений релиза 13.1. В нем мы также достигли важного рубежа в отношении сотрудничества с сообществом. В рамках этого релиза были приняты более 300 мерж-реквестов (в русской локализации GitLab запросы на слияние) от нашего обширного сообщества, и мы высоко ценим вклад каждого из вас! Читайте дальше, чтобы узнать больше о других замечательных улучшениях, таких, как виджеты мерж-реквестов для тестирования доступности, возможность пометить обсуждение в дизайне как решенное, уведомления об успешном завершении конвейера и многие другие!


Если вы хотите узнать, что вас ждет в следующем релизе, посмотрите наше видео по релизу 13.2.


Приглашаем на наши встречи.


GitLab MVP badge


MVP этого месяца Jacopo Beschi


Jacopo добавил новые уведомления по электронной почте после восстановления сборки конвейера. До сих пор GitLab отправлял уведомления по электронной почте, когда конвейер завершался неуспешно, но когда его работа восстанавливалась, никаких уведомлений об исправлении не отправлялось. Разработчикам приходилось неоднократно перезагружать страницу мерж-реквеста или конвейера, чтобы проверить его статус. Благодаря этому замечательному вкладу проблема была решена, что избавило разработчиков от ненужных хлопот.


Работа над этой фичей заняла около 8 месяцев и Jacopo справился с этой задачей отлично! Он получил подтверждение от 5 различных ревьюверов, отличные отклики от нас в GitLab и большой интерес от пользователей: более 30 голосов за этот тикет и почти 70 активных дискуссий, связанных с ним.


Jacopo, спасибо за этот потрясающий вклад, мы очень его ценим!


Основные фичи в GitLab 13.1


Управление оповещениями в GitLab


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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


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


В релизе 13.2 и далее мы планируем улучшить рабочие процессы оповещений и реагирования на инциденты с помощью интеграции с PagerDuty, отображения соответствующих метрик и логов оповещений, ассоциирования с перечнями задач (runbook) и создания специального Alert Integration Builder, чтобы ваши операторы могли самостоятельно обслуживать и беспрепятственно интегрировать GitLab с любыми инструментами мониторинга. Ознакомиться с ходом нашей работы и предложить свои идеи для будущих улучшений можно в эпике (в русской локализации GitLab цель) по управлению оповещениями.


Manage IT Alerts in GitLab


Документация по управлению оповещениями и оригинальный эпик.


Настройка стратегий переключения фич для разных окружений


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release


В этом релизе мы переработали пользовательский интерфейс переключаемых фич (feature flags), чтобы включить в него настройку стратегий для нескольких окружений. Без этого было намного сложнее управлять переключаемыми фичами и настраивать стратегии по мере увеличения количества окружений. Это решение позволяет более свободно создавать и применять их.


Set Feature Flag Strategy Across Environments


Документация по созданию переключаемых фич и оригинальный тикет.


Виджет тестирования доступности в мерж-реквесте


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


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


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


Accessibility Testing Merge Request Widget


Документация по тестированию на доступность и оригинальный тикет.


Возможность пометить обсуждение в дизайне как решенное


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


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


С релизом 13.1 вы сможете отметить любой комментарий как Решенный (Resolved), что означает, что обсуждение по нему завершено. Пины завершенных обсуждений исчезнут из дизайна, так что вы сможете сосредоточиться на том, что осталось. И, конечно же, если вам нужно что-то пересмотреть, все ваши завершенные обсуждения будут доступны в области Решенные обсуждения (Resolved Comment) в нижней части боковой панели. Там вы сможете найти их и проверить, какая ревизия была применена в данной точке.


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


Mark any Design thread as resolved


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


Ревью мерж-реквестов перенесены в Core


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Первоначально представленные в GitLab 11.4 в плане Premium, ревью мерж-реквестов позволяют ревьюверам отправлять несколько комментариев одновременно, что снижает количество оповещений для автора мерж-реквеста, а также обеспечивают более целостный и упорядоченный процесс ревью.


С тех пор мы пересмотрели место этой фичи в нашей стратегии определения планов, нацеленной на покупателя. Теперь мы рады объявить, что в рамках релиза 13.1 эта фича перенесена в план Core.


Merge Request Reviews moved to Core


Документация по ревью мерж-реквестов и оригинальный тикет.


Code Intelligence


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


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


Мы вдохновлялись огромной работой, проделанной нашими коллегами из Sourcegraph, и использовали формат LSIF. Благодаря этому встроенный в GitLab Code Intelligence теперь можно добавить в любой проект с помощью нового задания в файле .gitlab-ci.yml. Это задание будет отвечать за LSIF-отчет, после генерации которого вы будете видеть доступные действия Code Intelligence при наведении курсора на объекты в коде. С релизом 13.1 вам больше не понадобятся сторонние инструменты или IDE для этого.


Будущие итерации будут включать в себя возможность поиска ссылок, а также поддержку API. Вы можете следить за обновленями в эпике Code Intelligence.


Code Intelligence


Документация по Code Intelligence в GitLab и оригинальный тикет.


Управление переключаемыми фичами через списки пользователей


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release


GitLab раньше уже поддерживал возможность контролировать развертывание фич на основе ID пользователей. Однако многократно добавлять пользователей для каждой фичи или окружения может быть утомительно. Чтобы сделать этот процесс удобнее, мы добавили новую стратегию для переключаемых фич списки. Списки пользователей создаются и модифицируются с помощью API. После создания списка выберите стратегию list для вашей переключаемой фичи и соответствующий список. Если у вас уже есть созданные списки, вы сразу же сможете ими воспользоваться.


Control Feature Flags with User Lists


Документация по переключаемым фичам и оригинальный тикет.


График изменения покрытия кода в проекте


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


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


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


Graph code coverage changes over time for a project


Документация по отслеживанию покрытия кода и оригинальный тикет.


Специальное задание CI для управления требованиями


(ULTIMATE, GOLD) Стадия цикла DevOps: Plan


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


Мы рады представить первый шаг в этом направлении: возможность настроить в рамках стандартного CI-конвейера задания, которые при запуске будут отмечать все существующие требования как выполненные. Такое CI-задание может быть как ручным, так и автоматическим. А еще, как и другие задания CI, его можно настроить на разрешение неудачных выполнений (allow-failure), чтобы это задание не блокировало успешное завершение всего конвейера.



Документация по настройке выполнения требований и оригинальный эпик.


Другие улучшения в GitLab 13.1


Параметр expires_at в конечной точке /user/keys


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


Спасибо Petar Prokic (@pprokic) за этот вклад от сообщества!


Конечные точки в API пользователей /user/keys и /users/:id/keys теперь поддерживают опциональный параметр expires_at для определения даты истечения срока действия SSH-ключей. Это изменение поможет пользователям и организациям управлять последствиями в случаях скомпрометированных учетных записей в контролируемом окружении.


Документация по добавлению SSH-ключей и оригинальный мерж-реквест.


Конечная точка projects для API аудита событий


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


Спасибо Julien Millau (@devnied) за этот вклад от сообщества!


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


Документация по аудиту событий и оригинальный тикет.


Тренды и подробности в аналитике тикетов


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


Explore Trends & Details in Issue Analytics


Документация по аналитике тикетов и оригинальный тикет.


Ограничение доступа на основе IP-адресов теперь в Premium


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage


Ограничение доступа на основе IP-адресов теперь доступно для планов Premium и Silver. Эта фича позволяет вам ограничить доступ к группам и их контенту по одной или нескольким IP-подсетям. Включение ограничения доступа по IP гарантирует, что ваши данные не будут покидать пределы территории, не блокируя при этом доступ ко всему инстансу.


Документация по ограничению доступа по IP-адресам и оригинальный тикет.


Заголовок тикета теперь зафиксирован на странице


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan


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


Issue titles are now sticky


Документация по тикетам и оригинальный тикет.


Поддержка EditorConfig в Web IDE


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


При совместной работе над проектами разработчики часто следуют определенным стандартам и стилям программирования, чтобы поддерживать уровень читаемости и однородное форматирование в проекте. Эта настройка часто задается с помощью файла проекта .editorconfig, который содержит такие инструкции, как стиль отступов, размер отступов и символ конца строки.


При открытии файла Web IDE будет искать файл с именем .editorconfig в текущем каталоге и во всех родительских каталогах. Если такой файл будет найден и в нем есть настройки, соответствующие пути к открытому файлу, то эти настройки будут применены к нему. Web IDE обеспечивает поддержку большинства широко поддерживаемых функций EditorConfig, за исключением charset.


Документация по настройке Web IDE и оригинальный тикет.


Скрытие вступительной части YAML в статическом редакторе сайтов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Статические генераторы сайтов используют первые несколько строк (вступительную часть, "front matter") в начале файла Markdown, между двумя строками ---, для форматирования, настройки или парсинга страницы. Вступительная часть не должна отображаться вместе с содержимым страницы и должна при этом соответствовать определенным правилам форматирования.


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


В релизе GitLab 13.1 наш редактор скрывает любые YAML-форматированные вступительные части, содержащиеся в начале файла Markdown, чтобы избежать путаницы и непреднамеренного изменения форматирования. Эта часть остается редактируемой в режиме Markdown, доступном для переключения в правом нижнем углу редактора статических сайтов.


Документация по статическому редактору сайтов и оригинальный тикет.


Вставка изображений в Markdown в Web IDE


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


При работе с Markdown-контентом в Web IDE часто требуется добавлять в него изображения. В большинстве редакторов это требует поиска нужного изображения, добавления его в файловую структуру и последующей ссылки на него с помощью синтаксиса Markdown.


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



Документация по Markdown в Web IDE и оригинальный тикет.


Фильтр конвейеров по статусу и имени тега


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


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


Документация по странице конвейеров и оригинальный тикет.


Переменные CI/CD для инстансов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


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


Документация по переменным CI/CD для инстансов и оригинальный тикет.


Шаблоны для упрощения первоначальной настройки ключевых слов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Понять, как использовать новое ключевое слово rules, может быть сложно, особенно если ранее вы пользовались только only/except. Эти два ключевых слова отличаются принципиально: rules создает конвейер мерж-реквеста по умолчанию, а only/except этого не делает.


Чтобы упростить начало работы с ключевым словом rules и помочь вам быстрее получить первый успешный запуск конвейера, мы добавили шаблоны для двух самых популярных конфигураций workflow: rules. Теперь вам будет намного проще начинать работу с ключевыми словами, и вы сможете сфокусироваться на том, что действительно важно.


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


Скачивайте артефакты заданий проще и быстрее


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Secure


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


Мы хотели сделать так, чтобы получать доступ к файлу артефактов и включать его в отчеты стало проще и быстрее. Это особенно полезно для отчетов по сканированию безопасности и отчетов по качеству кода, которые могут быть нужны вам для использования в других инструментах.


С GitLab 13.1 мы добавили поддержку скачивания следующих типов отдельных отчетов по артефактам:


  • доступность
  • архив
  • cobertura
  • качество кода
  • сканирование контейнера
  • dast
  • сканирование зависимостей
  • dotenv
  • junit
  • управление лицензиями
  • сканирование лицензии
  • lsif
  • метрики
  • производительность

Эта фича доступна для всех пользователей GitLab. Однако типы отчетов по артефактам отличаются для разных тарифов.


Download job artifacts faster and easier


Документация по скачиванию артефактов и оригинальный тикет.


Экспорт списка уязвимостей с панелей безопасности группы


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


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


Просто перейдите на любую панель безопасности группы и кликните на новую кнопку Экспорт (Export). Ваш браузер автоматически начнет загрузку.


Export vulnerabilities list from Group Security Dashboards


Документация по экспорту уязвимостей с панели безопасности и оригинальный тикет.


Более явный поиск секретных ключей и новый отдельный шаблон поиска секретных ключей


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


Поиск секретных ключей вырос из под-фичи SAST до отдельной самостоятельной категории. Результаты поиска секретов теперь лучше видны: их можно увидеть в отдельном разделе в мерж-реквестах и во вкладках с информацией по безопасности конвейеров. Также поиск секретов теперь отображает статус конфигурации на странице настроек безопасности, а результаты поиска выводятся на панели безопасности проекта.


CI/CD конфигурация для поиска секретных ключей теперь предоставляется в отдельном шаблоне от GitLab и запускается как новый тип сканирования. Этот новый шаблон поиска секретных ключей теперь также включен в Auto DevOps. Мы рекомендуем вам использовать этот шаблон и затем убрать старое определение задания SAST secrets-sast из шаблона настройки SAST в файле SAST.gitlab-ci.yml. Мы сняли видео, которое объяснит вам процесс перехода на этот новый шаблон. Мы избавимся от старого определения SAST-задания по поиску секретных ключей в следующем релизе GitLab.



Документация по поиску секретных ключей и оригинальный эпик.


Сканирование SAST для Helm charts


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


Наш анализатор статического сканирования безопасности приложений (SAST) для манифестов Kubernetes теперь поддерживает Helm чарты. Это обновление также добавляет поддержку двух новых переменных окружения для точной настройки анализатора: KUBESEC_HELM_CHARTS_PATH и KUBESEC_HELM_OPTIONS.


Отдельное спасибо @agixid за вклад в разработку этой фичи!


SAST Scanning for Helm Charts


Документация по поддерживаемым языкам и фреймворкам и оригинальный тикет.


Документация по сине-зеленым развертываниям


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


Мы задокументировали пример сине-зеленого развертывания с использованием NGINX, который загружает развертывание напрямую из файла .gitlab-ci.yml. Этот пример поможет вам настроить ваши сине-зеленые развертывания, если вы используете похожую конфигурацию, и предоставляет набор действий, которые вы можете применять и для других типов приложений.



Документация по сине-зеленым развертываниям и оригинальный тикет.


Уведомления об успешном завершении конвейера после неудачи


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


Каждый раз, когда конвейер завершается с ошибкой, вы автоматически получаете уведомление по email. Однако, когда после неудачи конвейер восстанавливается и завершается успешно, автоматическое уведомление не приходит, что заставляет вас вручную проверять статус конвейера. В этом релизе мы рады представить вам фичу от @jacopo-beschi, которая решает эту проблему путем автоматической отправки уведомления, когда конвейер после неудачи завершается успешно.


Документация по уведомлениям о событиях GitLab и оригинальный тикет.


Улучшенная авторизация для файла состояния Terraform под управлением GitLab


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure


Изменение инфраструктуры это всегда большой риск. Оно должно проводиться под наблюдением, с аудитом и с ограничением для членов команды с определенными правами доступа. В GitLab 13.0 мы представили поддержку состояний Terraform под управлением GitLab с известным ограничением: вам приходилось предоставлять персональный токен доступа, чтобы работать с файлом состояния. Это плохо масштабировалось.


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


Документация по файлам состояния Terraform под управлением GitLab и оригинальный тикет.


Назначение оповещений GitLab членам команды


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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


Assign GitLab Alerts to team members


Документация по управлению оповещениями и оригинальный эпик.


Логирование назначений оповещений в системных заметках


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


Возможность проводить аудит оповещений важна для обратной связи и работы над улучшениями, однако в процессе устранения инцидентов редко находится время, чтобы задокументировать детали, которые понадобятся позже. В GitLab 13.0 мы добавили назначения оповещений членам команды в системные заметки на странице Оповещения (Alerts), чтобы вы могли обсудить их при ревью после инцидента.


Alert assignments logged in system notes


Документация по системным заметкам для оповещений и оригинальный тикет.


Отправка оповещений GitLab в Slack


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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


Документация по интеграции со Slack и оригинальный тикет.


Создание списков To-Do при назначении работы по оповещениям


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


Теперь вы можете назначать оповещения определенным членам команды, что поможет в организации оповещений, запущенных по триггеру, и делегированию расследования проблем. Добавление списка To-Do GitLab сообщит пользователям о том, что что-то требует их внимания.


Документация по назначению исполнителя по оповещению и оригинальный тикет.


Отображение внешних ссылок на панели метрик


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


Панели метрик наиболее полезны тогда, когда они позволяют добавлять больше деталей. В GitLab 13.1 вы сможете добавлять ссылки в меню More actions на вашей панели метрик. Так вы можете связать вашу панель метрик и панель управления с другими панелями метрик и инструментами устранения неполадок, которыми пользуется ваша команда.


Metric dashboard panels display external links


Документация по добавлению ссылок на панели Prometheus и оригинальный тикет.


Поддержка UTC для панелей метрик


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


GitLab 13.1 теперь позволяет панелям метрик отображать время в формате UTC, что позволяет членам распределенных команд видеть видеть одни и те же данные времени, независимо от того, где они находятся.


Metric dashboards now support UTC


Документация по изменению временной зоны на панели метрик и оригинальный тикет.


Панели задач с самомониторингом для пользователей Omnibus GitLab


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


В GitLab 13.1 пользователи Omnibus GitLab получат новую панель для проектов с самоуправлением. Эта панель управления будет работать из коробки и позволит проводить мониторинг состояния инстанса GitLab.



Документация по проектам с самомониторингом и оригинальный тикет.


Управление правилами сетевой безопасности контейнеров


(ULTIMATE, GOLD) Стадия цикла DevOps: Defend


С первым релизом пользовательского интерфейса для управления правилами сетевой безопасности контейнеров пользователи смогут легко сканировать список правил, применяемых в их проекте, и включать/выключать эти правила через пользовательский интерфейс. Вы можете посмотреть на новое управление правилами в Security & Compliance -> Threat Management -> Policies.


Policy Management for Container Network Policies


Документация по управлению правилами сетевой безопасности контейнеров и оригинальный эпик.


Сократилось время поиска через API


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Доступность


Если вы когда-нибудь пользовались API для поиска, то могли заметить, что для некоторых поисков время ответа могло достигать более 11000 мс. Очевидно, что это не очень эффективно.


В GitLab 13.1 мы оптимизировали некоторые запросы, решив проблему N+1 вызовов базы данных, и увидели 40%-е улучшение времени ответа. Поиск еще никогда не был таким быстрым!


Документация по поиску и оригинальный эпик.


Поиск со страницы проекта через выпадающее меню включает поиск по группе


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Доступность


В GitLab 13.1 при поиске со страницы проекта через выпадающее меню поиска вы теперь можете искать по группе, к которой принадлежит этот проект. До GitLab 13.1 результаты поиска не включали результаты в этой группе при поиске из проекта.


Search in a group from a project in the search box dropdown


Документация по расширенному глобальному поиску и оригинальный тикет.


Исправленные баги


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)


Вот некоторые баги, которые мы исправили в релизе 13.1, и о которых стоит упомянуть:



Все исправления багов в GitLab 13.1 можно посмотреть здесь.


Добавление события аудита при создании ключа SSH через API


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage


Спасибо Rajendra Kadam (@raju249) за вклад в разработку этой фичи!


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


Документация по добавлению SSH ключей для пользователя и мерж-реквест.


Аналитика вкладов в разработку теперь включает пользователей, подтверждающих мерж-реквесты


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


Аналитика вкладов в разработку помогает командам понимать, как нагрузка распределяется между участниками. Ранее вклад пользователей, подтверждающих мерж-реквесты (approvers) никак не учитывался, несмотря на их значимую роль в обеспечении необходимого ревью. Таблица со вкладами пользователей в группе теперь включает столбец Approved MRs, с возможностью сортировки по числу подтвержденных мерж-реквестов.


Contribution Analytics now show approvals


Документация по сортировке в аналитике вкладов и оригинальный тикет.


Членство в группе для пользователей с разными почтовыми доменами


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage


В GitLab 13.1 владельцы группы теперь могут добавлять в белый список почтовые адреса пользователей, принадлежащие к разным доменам, а не только к одному. Это позволит проводить более гибкую настройку доступа к вашей группе.


Group membership allow list supports multiple email domains


Документация по ограничению доступа по доменам и оригинальный тикет.


Быстрое назначение исполнителей


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan.


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


Assign issues faster


Документация по назначению тикета через комментарии и оригинальный тикет.


Распределение операций чтения по кластеру Gitaly (бета)


(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create


Кластер Gitaly позволяет вам реплицировать репозитории Git на нескольких теплых нодах Gitaly, что повышает надежность путем устранения единичных точек отказа.


В GitLab 13.1 операции чтения Git можно распределять по актуальным репликам Gitaly. Это позволяет более эффективно использовать доступные ресурсы и может улучшить производительность.


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


Документация по распределенным операциям чтения и оригинальный эпик.


Автоматическое аварийное переключение кластера Gitaly включено по умолчанию


(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create


Кластер Gitaly улучшает отказоустойчивость хранилища Git в GitLab: устраняет единичные точки отказа, обнаруживает сбои и автоматически переключается на реплику. Начиная с GitLab 13.1, когда Gitaly Cluster настроен, по умолчанию включаются выбор ноды-лидера для SQL и аварийное переключение.


Если во время аварийного переключения обнаруживаются нереплицированные операции записи, кластер переводится в режим только для чтения, чтобы предотвратить split brain (синдром расщепленного мозга). В будущем сильная согласованность потребует успешной операции записи на нескольких нодах Gitaly, прежде чем ответить сигналом об успехе, что предотвратит эту проблему и необходимость помечать кластер как доступный только для чтения.


Ранее в GitLab 13.0 вместо аварийного переключения по умолчанию был выбор лидера в памяти.


Документация по аварийному переключению и выбору лидера и оригинальный тикет.


Добавление и предварительный просмотр изображений в редакторе статических сайтов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Редактор статических сайтов предоставляет немедленную визуальную обратную связь при написании контента в Markdown и интуитивно понятные элементы управления форматированием для обеспечения согласованной и точной разметки. Однако в GitLab 13.0 визуальное редактирование ограничивалось текстом.


В GitLab 13.1 вы можете быстро добавлять изображения на свои страницы с помощью редактора статических сайтов. После нажатия иконки Изображение на панели форматирования просто укажите URL, добавьте необязательный текст ALT, и все готово. Ссылка может вести на изображения, уже размещенные в вашем проекте, ресурс, размещенный в сети доставки контента (CDN), или любой другой внешний URL. Редактор создает миниатюры для предварительного просмотра, так что вы cможете убедиться, что добавили правильное изображение и нет ссылок на отсутствующие изображения.


Документация по редактору статических сайтов и оригинальный тикет.


Терминал Web IDE и синхронизация файлов перенесены в Core


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


GitLab 11.6 представил Веб-терминалы для Web IDE. Через несколько релизов была добавлена синхронизация файлов с веб-терминалом, позволяющая веб-терминалу взаимодействовать с изменениями, внесенными через Web IDE.


Ранее в 2020 году GitLab решил переместить 18 фич в опенсорсный план Core нашего продукта. В этом релизе GitLab мы завершили работу по перемещению в Core как веб-терминала, так и утилиты синхронизации файлов. Мы рады предоставить эти фичи большему числу пользователей и посмотреть, для каких ситуаций и рабочих процессов вы можете их использовать.



Документация по интерактивным веб-терминалам для Web IDE и оригинальный тикет.


GitLab Runner 13.1


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Мы также выпускаем обработчик заданий GitLab версии 13.1. GitLab Runner это легкий, масштабируемый агент, который запускает ваши сборочные задания и отправляет результаты обратно в инстанс GitLab. Обработчик заданий GitLab работает совместно с GitLab CI/CD, опенсорсной службой непрерывной интеграции, входящей в состав GitLab.


Что нового:



Исправления ошибок



Список всех изменений находится в changelog GitLab Runner.


Документация по обработчику заданий GitLab.


Сначала выполняются тесты для измененных файлов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Как разработчик, вы хотите быстро получать обратную связь о ваших изменениях, включая результаты недавно написанных тестов. В крупных проектах, таких как GitLab, это может быть особенно трудно, когда приходится ждать до 45 минут только для того, чтобы увидеть, что новый юнит-тест проходит или что еще хуже терпит неудачу. Эта медлительность может привести к тому, что вы решите совсем пропустить разработку автотестов.


Разработчики Ruby могут сократить цикл обратной связи, используя gem TestFileFinder, чтобы найти тесты, предназначенные для измененного кода, а затем запустить эти тесты на ранней стадии в конвейере. Это подход MVC к решению проблемы, но мы надеемся, что он будет вам полезен. Мы с нетерпением ждем отзывов и идей в проекте TestFileFinder.


Документация по тестированию со скорейшим выявлением ошибок и оригинальный тикет.


Используйте метаданные, чтобы понять, как создаются ваши пакеты NuGet


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package


Когда пакет NuGet загружается в GitLab, задание открывает архив и читает файл .nuspec. Имя и версия пакета извлекаются сразу, но некоторые другие поля, например dependencies, project_url и tags, доступны, но не извлечены. Эти поля полезны для понимания того, как был построен пакет и каковы его зависимости.


В GitLab 13.1 мы рады сообщить, что теперь эти метаданные тоже будут извлечены при загрузке и добавлены в пользовательский интерфейс, чтобы вы могли проверить, что пакет собран правильно.


Документация по просмотру дополнительной информации о пакете и оригинальный тикет.


Динамические значки состояния тикета на панелях безопасности


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


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


Dynamic Issue status icons on Security Dashboards


Документация по панелям безопасности и оригинальный тикет.


На панелях безопасности сохраняются фильтры


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


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


Переход от панелей безопасности к странице уязвимостей и обратно ранее удалял все фильтры, примененные на панели. Ваши отзывы нам ясно дали понять, что улучшение этого перехода улучшит сортировку уязвимостей и управление ими. Ваши фильтры теперь сохраняются при перемещении между страницами уязвимостей и панелью безопасности, что значительно повышает эффективность управления уязвимостями. Это также соответствует знакомому шаблону UX в других местах GitLab, например при управлении списком To-Do.


Документация по панелям безопасности и оригинальный тикет.


Анализатор SAST для Rails теперь доступен для всех


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Secure


Мы хотим помочь разработчикам писать классный код и меньше беспокоиться о распространенных ошибках безопасности. Статическое тестирование безопасности приложений (SAST) помогает предотвратить уязвимости безопасности, позволяя разработчикам легко выявлять типичные проблемы безопасности по мере разработки кода и заранее их предотвращать. В рамках наших обязательств по управлению GitLab мы делаем наш анализатор SAST для Rails (Brakeman) доступным для каждого плана GitLab. Это позволит всем пользователям GitLab, работающим с Rails, использовать сканирования безопасности SAST для своих проектов. Мы продолжим переводить другие анализаторы SAST с открытым исходным кодом (OSS) в план Core. Вы можете следить за нашим эпиком SAST to Core, чтобы узнать, когда станут доступны другие анализаторы, и внести свой вклад в этот процесс.


Rails SAST analyzer available for all


Документация по поддерживаемым SAST языкам и фреймворкам и оригинальный тикет.


Поддержка API для установки нескольких стратегий переключаемых фич


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release


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


Документация по переключаемым фичам и изменениям в их поведении в GitLab 13.0 и 13.1 и оригинальный тикет.


Встроенная ссылка на руководство по развертыванию в AWS


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


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


In-product link to guidance for deploying to AWS


Документация по развертыванию в AWS и оригинальный тикет.


Возможность указать тип ресурса для ссылок в релизе


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


Теперь GitLab позволяет вам удобно указать тип ссылки на ресурс, добавленный в ваш релиз, с помощью выпадающего меню. Ранее, если вы добавляли ссылки к релизу, вы не могли указать тип ресурса. Теперь вы можете выбрать тип ресурса из следующих вариантов: Runbook, Package, Image или Other.


Specify asset types for Release links


Документация по ссылкам на ресурсы и оригинальный тикет.


Упрощенная настройка для интеграции Terraform


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure


Вы можете проще запускать фичи Terraform, интегрированные в GitLab, с одним из образов Terraform, предоставленных GitLab. Образы Terraform в GitLab расширяют официальные образы Terraform для бета-версий Terraform 0.12 и 0.13, включая простые команды для использования виджетов для мерж-реквестов без раздувания ваших файлов YAML для CI/CD.


Документация по пользовательской инфраструктуре и оригинальный тикет.


Сортировка столбцов для списка оповещений


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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


Column sorting for Alert list


Документация по управлению оповещениями и их сортировке и оригинальный тикет.


Легенды в виде таблицы на панели метрик


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


Без соответствующего контекста график бывает сложно понять. В GitLab 13.1 мы упростили сравнение данных при просмотре графиков, добавив легенду графика в виде таблицы.


Metric dashboard legends in table format


Документация по настройке панели метрик и оригинальный тикет.


На панели метрик отображаются ссылки на связанные панели


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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



Документация по добавлению ссылок на панели метрик и оригинальный эпик.


Проверка конфигурации панели метрик


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor


Настраивать файлы YAML для панели мониторинга может быть сложно. GitLab 13.1 добавляет проверку в файл YAML, чтобы помочь вам диагностировать проблемы с панелью метрик. Если YAML определение панели мониторинга ошибочно, появится предупреждающее сообщение.


Metrics dashboard configuration validation


Документация по проверке конфигурации панели метрик и оригинальный тикет.


На страницах статуса теперь показываются изображения


(ULTIMATE, GOLD) Стадия цикла DevOps: Monitor


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


Документация по настройке страниц статуса и оригинальный тикет.


Улучшения в GitLab Helm chart


(CORE, STARTER, PREMIUM, ULTIMATE) Доступность


  • Шаблон extraEnv теперь поддерживается в GitLab Helm charts. Это позволяет вам предоставлять дополнительные переменные окружения, такие как прокси-серверы, как для определенных чартов GitLab, так и глобально для всех чартов. Обратитесь к документации по глобальным настройкам или документации по подчартам, чтобы подробно узнать, как реализовать extraEnv.
  • Пользовательские аннотации, определенные в разделе deployment глобальных настроек в values.yml, теперь доступны во всех подчартах GitLab. Аннотации развертывания позволяют предоставлять доступ на уровне развертывания, а не на уровне ноды, например разрешая развертыванию читать из корзины Amazon S3, не давая всей ноде доступа к этой корзине. Подробнее о настройке аннотаций развертывания смотрите в документации по аннотациям.
  • Библиотеки PostgreSQL и клиент в образах контейнера GitLab обновились до PostgreSQL 12, что позволяет использовать больше версий PostgreSQL. Обратите внимание, что GitLab 13.1 по-прежнему поддерживает только PostgreSQL 11, но поддержка PostgreSQL 12 планируется в будущем релизе.
  • Для повышения безопасности теперь вы можете передать ключ-секрет Kubernetes для значений заголовков с высокими требованиями к безопасности, таких как токен авторизации для конечных точек при настройке уведомлений реестра. За информацией о настройке обращайтесь к документации по настройкам реестра.

Документация по GitLab Chart.


Новая команда аварийного восстановления Geo для проверки перед аварийным переключением


(PREMIUM, ULTIMATE) Доступность


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


В GitLab 13.1 добавлена команда Geo gitlab-ctl promotion-preflight-checks, которая перечисляет все необходимые предполетные проверки и требует от системных администраторов подтверждения, что все эти проверки выполнены. Команда автоматически запускается при запуске
gitlab-ctl promote-to-primary-node.


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


Документация по аварийному переключению и оригинальный эпик.


Уменьшен размер индекса для расширенного глобального поиска


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Доступность


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


Мы отключили частичное совпадение при поиске по коду в GitLab 13.1, что привело к уменьшению размера индекса на 75%. Если вам нужно частичное совпадение, вы можете использовать подстановочные знаки в своем поисковом запросе. Частичное совпадение для других типов контента, таких как тикеты или мерж-реквесты, по-прежнему поддерживается.


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


Документация по интеграции поиска Elasticsearch и оригинальный тикет.


Используйте роли IAM для зашифрованных корзин Amazon S3


(CORE, STARTER, PREMIUM, ULTIMATE) Доступность


Теперь вы можете использовать роли AWS IAM для доступа к зашифрованным корзинам S3. Ранее такие корзины не работали вообще. Чтобы узнать больше, смотрите документацию по хранилищу объектов.


Документация по хранилищу объектов и оригинальный тикет.




Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 13.1 released with Alert Management and Code Quality Enhancements.


Над переводом с английского работали cattidourden, maryartkey, ainoneko и rishavant.

Подробнее..

Установка и настройка cSvn

14.11.2020 22:12:09 | Автор: admin

cSvn это web-интерфейс к Subversion репозиториям. Основу cSvn представляет CGI-скрипт написанный на языке С.


В данной статье рассматривается установка и настройка cSvn для работы с использованием Nginx + uWsgi. Настройка серверных компонентов достаточно проста и практически не отличается от настройки cGit.


На стороне клиента работает элементарный JavaScript составляющий не более 350 строк и таблица стилей размером 24K в распакованном виде. Markdown-тексты обрабатываются на стороне сервера с помощью библиотеки md4c, которая успешно зарекомендовала себя в проекте KDE Plasma.


Стоит заметить, что с помощью cSvn можно просматривать не только собственные репозитории, но и настроить просмотр сторонних ресурсов по протоколам HTTPS и SVN.



Требования к системе


cSvn использует библиотеки libpcre2, md4c, libmagic, входящую в состав пакета File и libxml2. На сервере должны быть установлены: HTTP сервер Nginx, сервер uWsgi и, разумеется Apache Subversion.


Инсталляция продуктов


cSvn пакет состоит из двух частей. Первая представляет собой обычный Linux демон, который отвечает за разбор конфигурационного файла /etc/csvnrc. Вторая непосредственно является CGI-скриптом, отвечающим на HTTP запросы клиента. Обе части устанавливаются одновременно.


Исходные тексты


Получить исходный пакет cSvn можно двумя способами: загрузить с FTP-сервера или с помощью Subversion:


svn checkout svn://radix.pro/csvn/trunk csvn

Если использован второй способ, то перед сборкой пакета необходимо приготовить исходные тексты для их последующего конфигурирования. Для этого нужно воспользоваться скриптом bootstrap:


cd csvn./bootstarp

который установит Autotools средства, соберет коллекцию aclocal.m4 и создаст configure скрипт.


Сборка пакета


Сборка и установка cSvn ни чем не отличается от любых других продуктов, использующих средства Autoconf, Automake:


./configure --prefix=/usr \            --sysconfdir=/etc \            --with-config=/etc/csvnrc \            --with-controldir=/etc/rc.d \            --with-logrotatedir=/etc/logrotate.d \            --with-scriptdir=/var/www/htdocs/csvn \            --with-homedir=/var/lib/csvn \            --with-logdir=/var/log \            --with-piddir=/var/runmakemake install

Здесь, параметр --with-scriptdir определяет место установки CGI-скрипта и связанных с ним файлов, необходимых для работы сервера cSvn. Далее, в описании настроек сервера Nginx, мы будем использовать именно этот каталог. Разумеется, пользователи могут настроить работу cSvn и виртуального HTTP сервера относительно любого другоро каталога.


Права доступа


После инсталляции пакета cSvn необходимо отдать права на каталог /var/www/htdocs/csvn пользователю, от имени которого работает Nginx:


  chown -R nginx:nginx /var/www/htdocs/csvn


Subversion репозитории


Перед первым запуском сервера cSvn необходимо создать конфигурационный файл /etc/csvnrc, в котором должны быть определены все обязательные переменные и описан хотя бы один репозиторий.


На странице руководства csvnrc(5) приведен рабочий файл конфигурации сервера:


/etc/csvnrc:
svn-utc-offset = +0300;checkout-prefix-readonly = 'svn://radix.pro';checkout-prefix          = 'svn+ssh://svn@radix.pro';branches = 'branches';trunk    = 'trunk';tags     = 'tags';snapshots = 'tar.xz';css = '/.csvn/css/csvn.css';logo = '/.csvn/pixmaps/csvn-banner-280x280.png';logo-alt = "Radix.pro";logo-link = "https://radix.pro";main-menu-logo = '/.csvn/pixmaps/logo/SVN-logo-white-744x744.svg';favicon-path = '/.csvn/pixmaps/favicon';syntax-highlight-css = '_csvn.css';header = '/.csvn/html/header.html';footer = '/.csvn/html/footer.html';page-size = 200;owner = "Andrey V.Kosteltsev";author = "Andrey V.Kosteltsev";title = "Radix.pro SVN Repositories";description = "Subversion repositories hosted at radix.pro (St.-Petersburg)";keywords = "cSvn repositories";copyright = " Andrey V. Kosteltsev, 2019  2020.";copyright-notice = "Where any material of this site is being reproduced, published or issued to others the reference to the source is obligatory.";home-page = "https://radix.pro/";section "Tools" {  repo 'csvn' {    owner = "Andrey V.Kosteltsev";    title = "cSvn CGI Script";    description = "cSvn CGI Script  is a web frontend for Subversion Repositories";    home-page = "https://radix.pro/";  }}

Его можно использовать как начальный шаблон.


После создания конфигурационного файла /etc/csvnrc можно проверить работу csvnd(8) демона.


В случае работы на системе с BSD-like инициализацией, для запуска csvnd(8) демона достаточно выполнить команду


/etc/rc.d/rc.csvnd start

Для систем использующих systemd, необходимо воспользоваться утилитой systemctl:


systemctl enable csvnd.servicesystemctl start csvnd.service

Здесь необходимо упомянуть следующее...

При сборке и установке исходного пакета cSvn, устанавливается start/stop скрипт /etc/rc.d/rc.csvnd. Если же речь идет о системах использующих systemd, то для установки cSvn лучше использовать бинарный RPM или pacman пакет, поскольку в таких пакетах файл /etc/rc.d/rc.csvnd заменяется на Systemd Unit,


/usr/lib/systemd/system/csvnd.service:
[Unit]Description=The cSvn daemonAfter=network.target[Service]PIDFile=/var/run/csvnd.pidExecStart=/usr/sbin/csvnd --daemonize --inotify --config=/etc/csvnrcExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s TERM $MAINPID[Install]WantedBy=multi-user.target

устанавливаемый в каталог /usr/lib/systemd/system.


Если для используемой вами системы еще не создан пакет cSvn, то вы его можете приготовить самостоятельно, по инструкциям, приведенным к каталоге doc/build-packages.


Если же вы не хотите создавать пакет для вашей системы, то вы можете просто поместить файл csvnd.service в каталог /usr/lib/systemd/system/ и выполнить запуск демона самостоятельно.



После запуска csvnd(8) демона надо убедиться в существовании файла /dev/shm/csvn.bcf и, в случае его отсутствия посмотреть на ошибки приведенные в /var/log/csvnd.log файле.


Настройка uWsgi


Поскольку на этапе конфигурирования мы выбрали для инсталляции cSvn CGI-скрипта каталог /var/www/htdocs/csvn/, файл /etc/uwsgi/csvn.ini должен ваглядеть следующим образом:


/etc/uwsgi/csvn.ini:
[uwsgi]master          = trueplugins         = cgisocket          = /run/uwsgi/%n.sockuid             = nginxgid             = nginxprocname-master = uwsgi csvnprocesses       = 1threads         = 2cgi             = /var/www/htdocs/csvn/csvn.cgi

Здесь переменная cgi устанавливает полное имя CGI-скрипта cSvn.


Для запуска uWsgi демона на системах с BSD-like инициализацией, такой как Slackware, необходимо создать start/stop скрипт следующего вида:


/ets/rc.d/rc.csvn-uwsgi:
#!/bin/sh## uWSGI daemon control script.#CONF=csvnBIN=/usr/bin/uwsgiCONFDIR=/etc/uwsgiPID=/var/run/$CONF-uwsgi.piduwsgi_start() {  # Sanity checks.  if [ ! -r $CONFDIR/csvn.ini ]; then # no config files, exit:    echo "There are config files in $CONFDIR directory. Abort."    exit 1  fi  if [ -s $PID ]; then    echo "uWSGI for cSvn appears to already be running?"    exit 1  fi  echo "Starting uWSGI for cSvn server daemon..."  if [ -x $BIN ]; then    /bin/mkdir -p /run/uwsgi    /bin/chown nginx:nginx /run/uwsgi    /bin/chmod 0755 /run/uwsgi    $BIN --thunder-lock --pidfile $PID --daemonize /var/log/csvn-uwsgi.log --ini $CONFDIR/$CONF.ini  fi}uwsgi_stop() {  echo "Shutdown uWSGI for cSvn gracefully..."  /bin/kill -INT $(cat $PID)  /bin/rm -f $PID}uwsgi_reload() {  echo "Reloading uWSGI for cSvn configuration..."  kill -HUP $(cat $PID)}uwsgi_restart() {  uwsgi_stop  sleep 3  uwsgi_start}case "$1" in  start)    uwsgi_start    ;;  stop)    uwsgi_stop    ;;  reload)    uwsgi_reload    ;;  restart)    uwsgi_restart    ;;  *)  echo "usage: `basename $0` {start|stop|reload|restart}"esac

Дать ему права на выполнение


  chmod a+x /ets/rc.d/rc.csvn-uwsgi

и добавить следующие строчки в файлы /etc/rc.d/rc.M, /etc/rc.d/rc.6, соответственно:


/etc/rc.d/rc.M:
# Start uWSGI for cSvn server:if [ -x /etc/rc.d/rc.csvn-uwsgi ]; then  /etc/rc.d/rc.csvn-uwsgi startfi

/etc/rc.d/rc.6:
# Stop uWSGI for cSvn server:if [ -x /etc/rc.d/rc.csvn-uwsgi ]; then  /etc/rc.d/rc.csvn-uwsgi stopfi


Настройка Nginx


Конфигурационный файл, для выбранного нами каталога установки и домена csvn.example.org должен выглядеть следующим образом:


/etc/nginx/vhosts/csvn.example.org.conf:
## cSvn server:#    server {        listen 80;        server_name csvn.example.org;        return 301 https://csvn.example.org$request_uri;    }    server {        listen 443 ssl;        server_name csvn.example.org;        root /var/www/htdocs/csvn;        charset UTF-8;        #        # see:        #   https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security ,        #   https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html        #        # see also: http://classically.me/blogs/how-clear-hsts-settings-major-browsers        # and do not include includeSubdomains; parameter into line:        #        add_header Strict-Transport-Security "max-age=63072000; preload";        error_log /var/log/nginx/csvn.example.org-error.log;        access_log /var/log/nginx/csvn.example.org-access.log;        keepalive_timeout        60;        ssl_certificate          /etc/letsencrypt/live/csvn.example.org/fullchain.pem;        ssl_certificate_key      /etc/letsencrypt/live/csvn.example.org/privkey.pem;        ssl_trusted_certificate  /etc/letsencrypt/live/csvn.example.org/chain.pem;        ssl_protocols            SSLv3 TLSv1 TLSv1.1 TLSv1.2;        ssl_ciphers              "RC4:HIGH:!aNULL:!MD5:!kEDH";        gzip on;        gzip_disable "msie6";        gzip_comp_level 6;        gzip_min_length 1100;        gzip_buffers 16 8k;        gzip_proxied any;        gzip_types text/plain text/css text/js text/xml text/javascript                   image/svg+xml image/gif image/jpeg image/png                   application/json application/x-javascript application/xml application/xml+rss application/javascript                   font/truetype font/opentype application/font-woff application/font-woff2                   application/x-font-ttf application/x-font-opentype application/vnd.ms-fontobject application/font-sfnt;        #        # Serve static content with nginx        #        #        # Rewrite rules for versioning CSS + JS thtouh filemtime directive        #        location ~* ^.+.(css|js)$ {            rewrite ^(.+).(d+).(css|js)$ $1.$3 last;            expires 31536000s;            access_log off;            log_not_found off;            add_header Pragma public;            add_header Cache-Control "max-age=31536000, public";        }        #        # Caching of static files        #        location ~* .(eot|gif|gz|gzip|ico|jpg|jpeg|otf|pdf|png|svg|svgz|swf|tar|t?gz|woff|zip)$ {            expires 31536000s;            access_log off;            log_not_found off;            add_header Pragma public;            add_header Cache-Control "max-age=31536000, public";        }        location ~ ^/favicon.ico$ {            root /u3/nginx/vhosts/csvn;            access_log off;            log_not_found off;            expires 30d;        }        location = /robots.txt {            allow all;            log_not_found off;            access_log off;        }        location / {            try_files $uri @csvn;        }        location @csvn {            gzip off;            include uwsgi_params;            uwsgi_modifier1 9;            uwsgi_pass unix:/run/uwsgi/csvn.sock;        }    }

После создания файла /etc/nginx/vhosts/csvn.example.org.conf его необходимо включить в основной конфигурационный файл Nginx:


/etc/nginx/nginx.conf:
    include /etc/nginx/vhosts/csvn.example.org.conf;

После запуска uWsgi и Nginx можно заняться настройкой репозториев используя руководство csvnrc(5).



Заключительная настройка


Все необходимые файлы для работы на стороне web-клиента находятся в каталоге /var/www/htdocs/csvn/.csvn/. Редактируя файл /.csvn/html/header.html и меняя значения переменных в файле /etc/csvnrc, пользователь может сменить favicon.ico, поменять тему подсветки синтаксиса, выбрать изображения для собственных репозиториев, задать ключевые слова для поисковых систем, а также выполнить множество других настроек своего сервера.


Внешний вид интерфейса определяется единственным CSS-файлом и поэтому, пользователь может поменять тему web-интерфейса так, как ему будет необходимо.


Посмотреть на рабочую копию cSvn сервера можно здесь.

Подробнее..

Современный Web-UI для SVN в 2020 году

15.11.2020 00:20:52 | Автор: admin

cSvn это web-интерфейс к Subversion репозиториям. Основу cSvn представляет CGI-скрипт написанный на языке С.


В мае 2020 года был опубликован релиз очередной версии Apache Subversion 1.14.0. В свете этого события, был создан новый, современный web-интерфейс для просмотра Subversion репозиториев на любых устройствах. Это весьма позитивная новость для тех, кто использует централизованные системы версионного контроля по тому, что до вчерашнего дня существовал лишь один достойный web-UI (WebSVN), написанный на PHP и, к сожалению, отстающий от современных требований.


В данной статье рассматривается установка и настройка cSvn для работы с использованием Nginx + uWsgi. Настройка серверных компонентов достаточно проста и практически не отличается от настройки cGit.


На стороне клиента работает элементарный JavaScript составляющий не более 350 строк и таблица стилей размером 24K в распакованном виде. Markdown-тексты обрабатываются на стороне сервера с помощью библиотеки md4c, которая успешно зарекомендовала себя в проекте KDE Plasma.


Стоит заметить, что с помощью cSvn можно просматривать не только собственные репозитории, но и настроить просмотр сторонних ресурсов по протоколам HTTPS и SVN.



Требования к системе


cSvn использует библиотеки libpcre2, md4c, libmagic, входящую в состав пакета File и libxml2. На сервере должны быть установлены: HTTP сервер Nginx, сервер uWsgi и, разумеется Apache Subversion.


Инсталляция продуктов


cSvn пакет состоит из двух частей. Первая представляет собой обычный Linux демон, который отвечает за разбор конфигурационного файла /etc/csvnrc. Вторая непосредственно является CGI-скриптом, отвечающим на HTTP запросы клиента. Обе части устанавливаются одновременно.


Исходные тексты


Получить исходный пакет cSvn можно двумя способами: загрузить с FTP-сервера или с помощью Subversion:


svn checkout svn://radix.pro/csvn/trunk csvn

Если использован второй способ, то перед сборкой пакета необходимо приготовить исходные тексты для их последующего конфигурирования. Для этого нужно воспользоваться скриптом bootstrap:


cd csvn./bootstarp

который установит Autotools средства, соберет коллекцию aclocal.m4 и создаст configure скрипт.


Сборка пакета


Сборка и установка cSvn ни чем не отличается от любых других продуктов, использующих средства Autoconf, Automake:


./configure --prefix=/usr \            --sysconfdir=/etc \            --with-config=/etc/csvnrc \            --with-controldir=/etc/rc.d \            --with-logrotatedir=/etc/logrotate.d \            --with-scriptdir=/var/www/htdocs/csvn \            --with-homedir=/var/lib/csvn \            --with-logdir=/var/log \            --with-piddir=/var/runmakemake install

Здесь, параметр --with-scriptdir определяет место установки CGI-скрипта и связанных с ним файлов, необходимых для работы сервера cSvn. Далее, в описании настроек сервера Nginx, мы будем использовать именно этот каталог. Разумеется, пользователи могут настроить работу cSvn и виртуального HTTP сервера относительно любого другоро каталога.


Права доступа


После инсталляции пакета cSvn необходимо отдать права на каталог /var/www/htdocs/csvn пользователю, от имени которого работает Nginx:


  chown -R nginx:nginx /var/www/htdocs/csvn


Subversion репозитории


Перед первым запуском сервера cSvn необходимо создать конфигурационный файл /etc/csvnrc, в котором должны быть определены все обязательные переменные и описан хотя бы один репозиторий.


На странице руководства csvnrc(5) приведен рабочий файл конфигурации сервера:


/etc/csvnrc:
svn-utc-offset = +0300;checkout-prefix-readonly = 'svn://radix.pro';checkout-prefix          = 'svn+ssh://svn@radix.pro';branches = 'branches';trunk    = 'trunk';tags     = 'tags';snapshots = 'tar.xz';css = '/.csvn/css/csvn.css';logo = '/.csvn/pixmaps/csvn-banner-280x280.png';logo-alt = "Radix.pro";logo-link = "https://radix.pro";main-menu-logo = '/.csvn/pixmaps/logo/SVN-logo-white-744x744.svg';favicon-path = '/.csvn/pixmaps/favicon';syntax-highlight-css = '_csvn.css';header = '/.csvn/html/header.html';footer = '/.csvn/html/footer.html';page-size = 200;owner = "Andrey V.Kosteltsev";author = "Andrey V.Kosteltsev";title = "Radix.pro SVN Repositories";description = "Subversion repositories hosted at radix.pro (St.-Petersburg)";keywords = "cSvn repositories";copyright = " Andrey V. Kosteltsev, 2019  2020.";copyright-notice = "Where any material of this site is being reproduced, published or issued to others the reference to the source is obligatory.";home-page = "https://radix.pro/";section "Tools" {  repo 'csvn' {    owner = "Andrey V.Kosteltsev";    title = "cSvn CGI Script";    description = "cSvn CGI Script  is a web frontend for Subversion Repositories";    home-page = "https://radix.pro/";  }}

Его можно использовать как начальный шаблон.


После создания конфигурационного файла /etc/csvnrc можно проверить работу csvnd(8) демона.


В случае работы на системе с BSD-like инициализацией, для запуска csvnd(8) демона достаточно выполнить команду


/etc/rc.d/rc.csvnd start

Для систем использующих systemd, необходимо воспользоваться утилитой systemctl:


systemctl enable csvnd.servicesystemctl start csvnd.service

Здесь необходимо упомянуть следующее...

При сборке и установке исходного пакета cSvn, устанавливается start/stop скрипт /etc/rc.d/rc.csvnd. Если же речь идет о системах использующих systemd, то для установки cSvn лучше использовать бинарный RPM или pacman пакет, поскольку в таких пакетах файл /etc/rc.d/rc.csvnd заменяется на Systemd Unit,


/usr/lib/systemd/system/csvnd.service:
[Unit]Description=The cSvn daemonAfter=network.target[Service]PIDFile=/var/run/csvnd.pidExecStart=/usr/sbin/csvnd --daemonize --inotify --config=/etc/csvnrcExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s TERM $MAINPID[Install]WantedBy=multi-user.target

устанавливаемый в каталог /usr/lib/systemd/system.


Если для используемой вами системы еще не создан пакет cSvn, то вы его можете приготовить самостоятельно, по инструкциям, приведенным к каталоге doc/build-packages.


Если же вы не хотите создавать пакет для вашей системы, то вы можете просто поместить файл csvnd.service в каталог /usr/lib/systemd/system/ и выполнить запуск демона самостоятельно.



После запуска csvnd(8) демона надо убедиться в существовании файла /dev/shm/csvn.bcf и, в случае его отсутствия посмотреть на ошибки приведенные в /var/log/csvnd.log файле.


Настройка uWsgi


Поскольку на этапе конфигурирования мы выбрали для инсталляции cSvn CGI-скрипта каталог /var/www/htdocs/csvn/, файл /etc/uwsgi/csvn.ini должен ваглядеть следующим образом:


/etc/uwsgi/csvn.ini:
[uwsgi]master          = trueplugins         = cgisocket          = /run/uwsgi/%n.sockuid             = nginxgid             = nginxprocname-master = uwsgi csvnprocesses       = 1threads         = 2cgi             = /var/www/htdocs/csvn/csvn.cgi

Здесь переменная cgi устанавливает полное имя CGI-скрипта cSvn.


Для запуска uWsgi демона на системах с BSD-like инициализацией, такой как Slackware, необходимо создать start/stop скрипт следующего вида:


/ets/rc.d/rc.csvn-uwsgi:
#!/bin/sh## uWSGI daemon control script.#CONF=csvnBIN=/usr/bin/uwsgiCONFDIR=/etc/uwsgiPID=/var/run/$CONF-uwsgi.piduwsgi_start() {  # Sanity checks.  if [ ! -r $CONFDIR/csvn.ini ]; then # no config files, exit:    echo "There are config files in $CONFDIR directory. Abort."    exit 1  fi  if [ -s $PID ]; then    echo "uWSGI for cSvn appears to already be running?"    exit 1  fi  echo "Starting uWSGI for cSvn server daemon..."  if [ -x $BIN ]; then    /bin/mkdir -p /run/uwsgi    /bin/chown nginx:nginx /run/uwsgi    /bin/chmod 0755 /run/uwsgi    $BIN --thunder-lock --pidfile $PID --daemonize /var/log/csvn-uwsgi.log --ini $CONFDIR/$CONF.ini  fi}uwsgi_stop() {  echo "Shutdown uWSGI for cSvn gracefully..."  /bin/kill -INT $(cat $PID)  /bin/rm -f $PID}uwsgi_reload() {  echo "Reloading uWSGI for cSvn configuration..."  kill -HUP $(cat $PID)}uwsgi_restart() {  uwsgi_stop  sleep 3  uwsgi_start}case "$1" in  start)    uwsgi_start    ;;  stop)    uwsgi_stop    ;;  reload)    uwsgi_reload    ;;  restart)    uwsgi_restart    ;;  *)  echo "usage: `basename $0` {start|stop|reload|restart}"esac

Дать ему права на выполнение


  chmod a+x /ets/rc.d/rc.csvn-uwsgi

и добавить следующие строчки в файлы /etc/rc.d/rc.M, /etc/rc.d/rc.6, соответственно:


/etc/rc.d/rc.M:
# Start uWSGI for cSvn server:if [ -x /etc/rc.d/rc.csvn-uwsgi ]; then  /etc/rc.d/rc.csvn-uwsgi startfi

/etc/rc.d/rc.6:
# Stop uWSGI for cSvn server:if [ -x /etc/rc.d/rc.csvn-uwsgi ]; then  /etc/rc.d/rc.csvn-uwsgi stopfi


Настройка Nginx


Конфигурационный файл, для выбранного нами каталога установки и домена csvn.example.org должен выглядеть следующим образом:


/etc/nginx/vhosts/csvn.example.org.conf:
## cSvn server:#    server {        listen 80;        server_name csvn.example.org;        return 301 https://csvn.example.org$request_uri;    }    server {        listen 443 ssl;        server_name csvn.example.org;        root /var/www/htdocs/csvn;        charset UTF-8;        #        # see:        #   https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security ,        #   https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html        #        # see also: http://classically.me/blogs/how-clear-hsts-settings-major-browsers        # and do not include includeSubdomains; parameter into line:        #        add_header Strict-Transport-Security "max-age=63072000; preload";        error_log /var/log/nginx/csvn.example.org-error.log;        access_log /var/log/nginx/csvn.example.org-access.log;        keepalive_timeout        60;        ssl_certificate          /etc/letsencrypt/live/csvn.example.org/fullchain.pem;        ssl_certificate_key      /etc/letsencrypt/live/csvn.example.org/privkey.pem;        ssl_trusted_certificate  /etc/letsencrypt/live/csvn.example.org/chain.pem;        ssl_protocols            SSLv3 TLSv1 TLSv1.1 TLSv1.2;        ssl_ciphers              "RC4:HIGH:!aNULL:!MD5:!kEDH";        gzip on;        gzip_disable "msie6";        gzip_comp_level 6;        gzip_min_length 1100;        gzip_buffers 16 8k;        gzip_proxied any;        gzip_types text/plain text/css text/js text/xml text/javascript                   image/svg+xml image/gif image/jpeg image/png                   application/json application/x-javascript application/xml application/xml+rss application/javascript                   font/truetype font/opentype application/font-woff application/font-woff2                   application/x-font-ttf application/x-font-opentype application/vnd.ms-fontobject application/font-sfnt;        #        # Serve static content with nginx        #        #        # Rewrite rules for versioning CSS + JS thtouh filemtime directive        #        location ~* ^.+.(css|js)$ {            rewrite ^(.+).(d+).(css|js)$ $1.$3 last;            expires 31536000s;            access_log off;            log_not_found off;            add_header Pragma public;            add_header Cache-Control "max-age=31536000, public";        }        #        # Caching of static files        #        location ~* .(eot|gif|gz|gzip|ico|jpg|jpeg|otf|pdf|png|svg|svgz|swf|tar|t?gz|woff|zip)$ {            expires 31536000s;            access_log off;            log_not_found off;            add_header Pragma public;            add_header Cache-Control "max-age=31536000, public";        }        location ~ ^/favicon.ico$ {            root /u3/nginx/vhosts/csvn;            access_log off;            log_not_found off;            expires 30d;        }        location = /robots.txt {            allow all;            log_not_found off;            access_log off;        }        location / {            try_files $uri @csvn;        }        location @csvn {            gzip off;            include uwsgi_params;            uwsgi_modifier1 9;            uwsgi_pass unix:/run/uwsgi/csvn.sock;        }    }

После создания файла /etc/nginx/vhosts/csvn.example.org.conf его необходимо включить в основной конфигурационный файл Nginx:


/etc/nginx/nginx.conf:
    include /etc/nginx/vhosts/csvn.example.org.conf;

После запуска uWsgi и Nginx можно заняться настройкой репозториев используя руководство csvnrc(5).



Заключительная настройка


Все необходимые файлы для работы на стороне web-клиента находятся в каталоге /var/www/htdocs/csvn/.csvn/. Редактируя файл /.csvn/html/header.html и меняя значения переменных в файле /etc/csvnrc, пользователь может сменить favicon.ico, поменять тему подсветки синтаксиса, выбрать изображения для собственных репозиториев, задать ключевые слова для поисковых систем, а также выполнить множество других настроек своего сервера.


Внешний вид интерфейса определяется единственным CSS-файлом и поэтому, пользователь может поменять тему web-интерфейса так, как ему будет необходимо.


Посмотреть на рабочую копию cSvn сервера можно здесь.

Подробнее..

Перевод Вышел релиз GitLab 13.7 с проверяющими для мерж-реквестов и автоматическим откатом при сбое

12.01.2021 16:20:24 | Автор: admin

Картинка для привлечения внимания


Ну и год же был 2020! Мы счастливы представить релиз 13.7 с более чем 45 фичами и улучшениями поставки ПО, вышедший как раз к праздникам.


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


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


Вот что вас ждёт в релизе 13.7:


Улучшенное управление проектами для развития совместной работы


Мерж-реквесты (в русской локализации GitLab запросы на слияние) имеют решающее значение для развития совместной работы и могут быть напрямую связаны с соответствующими тикетами, предоставляя центральное место для общения посредством комментариев, предложений по изменениям в коде и ревью кода. В этом релизе мы добавили проверяющих для мерж-реквестов способ улучшить процесс ревью кода, сделав его более лёгким и организованным. Теперь вы сможете быстро выяснить, кто участвовал в мерж-реквесте, или запросить у кого-то ревью, отправив соответствующее уведомление.


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


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


Улучшена автоматизация релизов и гибкость развёртывания


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


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


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


Мы также выпустили первую официально поддерживаемую бета-версию контейнера обработчика заданий GitLab для Red Hat OpenShift, а также нашего сертифицированного оператора обработчиков заданий, чтобы дать вам больше свободы в том, как вы выпускаете релизы с GitLab. Мы работаем над тем, чтобы сделать эту фичу общедоступной, так что следите за новостями в будущих релизах.


Более надёжное и эффективное управление пакетами и зависимостями


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


Мы также внесли улучшения в прокси зависимостей от GitLab; кстати, эта фича была перенесена в Core в GitLab 13.6.


Теперь вы можете вписаться в ограничения запросов Docker и ускорить работу конвейеров (в русской локализации GitLab сборочные линии) благодаря кэшированию образов контейнеров, размещённых на DockerHub, и быть уверенными в надёжности и эффективности работы с образами.


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


И, наконец, вы можете использовать предопределённые переменные с прокси зависимостей взамен того, чтобы полагаться на свои собственные определённые переменные или вшитые значения в вашем файле gitlab.ci-yml. Таким образом, появился более масштабируемый и эффективный способ начать проксирование и кэширование образов.


И это ещё не всё!


Взгляните на ещё несколько классных новых фич релиза 13.7:



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


6-7го января у нас прошёл виртуальный хакатон, узнайте больше об этом и будущих мероприятиях от GitLab здесь.


GitLab MVP badge


MVP этого месяца Rachel Gottesman


Rachel активно помогала нашей команде технических писателей внедрить согласованный стиль в документации для исправления использования будущего времени в наших документах. В релизе 13.7 Rachel открыла 33 мерж-реквеста, чем помогла нашей команде справиться с этой важной и кропотливой задачей. Спасибо, Rachel!


Основные фичи релиза GitLab 13.7


Проверяющие для мерж-реквестов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Попросить коллегу просмотреть ваш код должно быть обычной частью рабочего процесса, но иногда это бывает неоправданно сложно. Такая простая задача, как запрос на ревью, может привести к путанице. Например, как именно следует запрашивать: через электронное письмо, комментарий, сообщение в чате? Без формального механизма ревью мерж-реквестов могут быть непоследовательными, и за их проведением будет сложно уследить. Раньше уже можно было назначить проверяющего на мерж-реквест, но и автор, и рецензент отображались в одном и том же поле Assignee, что не позволяло другим членам команды узнать, кто за что отвечал в этом мерж-реквесте.


GitLab 13.7 представляет новую фичу теперь авторы мерж-реквеста могут запросить ревью у конкретных пользователей. В новом поле Reviewers пользователи могут быть назначены проверяющими для мерж-реквеста аналогичным образом, как назначаются ответственные (assignee). Назначенные на ревью пользователи получат уведомление, предлагающее им просмотреть мерж-реквест. Таким образом, теперь существует формальный процесс запроса ревью для мерж-реквеста и уточняются роли каждого пользователя в работе над ним.


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


Reviewers for Merge Requests


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


Автоматический откат в случае сбоя


(ULTIMATE, GOLD) Стадия цикла DevOps: Release


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



Документация по автоматическому откату при сбое и оригинальный тикет.


Клонирование тикета через быстрое действие


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan


Чтобы сделать создание похожих тикетов более эффективным, тикеты теперь поддерживают быстрое действие /clone, которое создаёт в том же проекте новый тикет с идентичными названием, описанием и метаданными. Быстрое действие /clone заменяет более трудоёмкий процесс, который включал в себя несколько шагов для создания тикета, копирования идентификатора или пути к исходному тикету и использование быстрого действия copy_meta.


По умолчанию тикеты клонируются в тот же проект и не включают в себя системные заметки и комментарии, но вы можете изменить поведение по умолчанию при клонировании.


Clone an issue with a quick action


Документация по быстрым действиям и оригинальный тикет.


Обработчик заданий GitLab для Red Hat OpenShift


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Наконец-то стал доступен образ контейнера обработчика заданий GitLab (GitLab runner) для платформы контейнеров Red Hat OpenShift! Чтобы установить обработчик заданий на OpenShift, воспользуйтесь новым оператором обработчиков заданий GitLab. Он доступен на бета-канале в Red Hat's Operator Hub веб-консоли для администраторов кластеров OpenShift, уже развёрнутой по умолчанию на платформе, где они могут найти и выбрать операторы для установки на своём кластере. На платформе контейнеров OpenShift Operator Hub уже развёрнут по умолчанию. Мы планируем перенести оператор обработчика заданий GitLab на стабильный канал, а в начале 2021 года в общий доступ. Наконец, мы также разрабатываем оператор для GitLab, так что следите за будущими публикациями.


GitLab Runner for Red Hat OpenShift


Документация по установке на OpenShift и оригинальный тикет.


Просмотр статуса развёртываний на странице окружений


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


Ранее на странице окружений не было никакого способа узнать о том, что сейчас выполняется развёртывание. Теперь на этой странице отображаются статусы развёртываний и предупреждения, благодаря чему вы можете принять решение о том, какие действия нужно предпринять, основываясь на статусе развёртывания (успешное, неудачное или текущее). Например, можно остановить текущее развёртывание или откатить завершённое.


Show deployment status on the Environments page


Документация по работе с окружениями и оригинальный тикет.


Задавайте через пользовательский интерфейс процент трафика для канареечного развёртывания


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release


В GitLab 13.7 вы можете менять процент трафика для канареечного развёртывания (значение canary-weight) непосредственно с досок развёртывания в пользовательском интерфейсе. Вы также можете менять это значение из gitlab-ci.yml и через API, но сделав это в пользовательском интерфейсе, вы сможете наблюдать за развёртыванием и при необходимости отмасштабировать поды прямо с досок развёртывания. Так у вас будет больше контроля над ручными или инкрементальными развёртываниями по таймеру, а также вы сможете лучше контролировать и даже снижать риски.


Set deployment traffic weight via the UI


Документация по заданию процента трафика для канареечного развёртывания и оригинальный тикет.


Просмотр частоты развёртываний через API


(ULTIMATE, GOLD) Стадия цикла DevOps: Release


В этом релизе в рамках первой итерации встроенной в GitLab поддержки метрик DORA4 была добавлена возможность узнавать частоту развёртываний на уровне проекта через API. Это позволяет отслеживать эффективность развёртывания с течением времени, легко находить узкие места и при необходимости быстро принимать меры по корректировке.


API support for deployment frequency


Документация по аналитике проектов и оригинальный тикет.


Поддержка нескольких файлов манифеста в проекте


(PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure


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


Support multiple manifest files in a project


Документация по настройке репозитория с агентом Kubernetes и оригинальный тикет.


Импорт требований из внешних инструментов


(ULTIMATE, GOLD) Стадия цикла DevOps: Plan


Для эффективной совместной работы очень важно, чтобы все ваши требования хранились в одном месте, поэтому мы рады сообщить, что теперь вы можете импортировать требования из CSV-файлов!


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


Import requirements from external tools


Документация по импорту требований из CSV-файла и оригинальный тикет.


Несколько конечных точек HTTP для оповещений


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Monitor


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


Integrate alerting tools with multiple HTTP endpoints


Документация по конечным точкам для оповещений и оригинальный эпик.


Синхронизация групп на GitLab.com с помощью SAML


(SILVER, GOLD) Стадия цикла DevOps: Manage


В GitLab 13.7 вы можете привязать группу в вашем поставщике учётных записей к группе на GitLab.com с помощью SAML. Членство в группе будет обновляться, когда пользователь войдёт в учётную запись GitLab через своего провайдера SAML. Эта фича снижает необходимость в ручном назначении групп, что снижает загрузку по группам для администраторов GitLab. Синхронизация групп также улучшает адаптацию новых членов групп, избавляя их от необходимости запрашивать доступ у администраторов групп GitLab.


SAML Group Sync for GitLab.com


Документация по синхронизации групп с помощью SAML и оригинальный эпик.


Другие улучшения в GitLab 13.7


DevOps Adoption


(ULTIMATE) Стадия цикла DevOps: Manage


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


  • Убедитесь, что вы получаете ожидаемую отдачу от использования GitLab.
  • Узнайте, какие группы отстают во внедрении GitLab, и помогайте им с настройкой DevOps.
  • Узнайте, какие группы используют определённые фичи, такие как конвейеры, и могут поделиться своим опытом с другими группами, которые хотят начать ими пользоваться.

DevOps Adoption


Документация по DevOps Adoption и оригинальный тикет.


Улучшенный пользовательский интерфейс для создания проектов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


Документация по созданию проектов и оригинальный тикет.


Ограничение создания проектов и групп для внешних аккаунтов


(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


Документация по настройкам пользователя через SAML и оригинальный тикет.


Сортировка по числу блокируемых тикетов


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan


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


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


В версии 13.7 вы можете использовать фильтр Блокирует другие тикеты для списка тикетов, чтобы отсортировать его по числу блокируемых тикетов.


Sort issues by the number of issues they are blocking


Документация по сортировке и оригинальный тикет.


Просмотр файлов в мерж-реквестах по одному


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


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


В GitLab 13.7 мы добавили возможность просматривать файлы по одному при просмотре мерж-реквеста. При переходе на вкладку мерж-реквеста Изменения кликните на иконку с шестерёнками и поставьте галочку Показывать файлы по одному. После выбора этого параметра вы сможете просматривать файлы по одному, переключаясь между ними при помощи кнопок Предыдущий и Следующий.


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


Choose to show one file at a time directly from merge requests


Документация по ревью и управлению мерж-реквестами и оригинальный тикет.


Просмотр изменений мерж-реквеста в VS Code


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


При ревью мерж-реквестов в VS Code для обращения к изменениям зачастую приходится делать checkout ветки и затем пытаться разобраться в диффе между этой веткой и целевой веткой мержа.


С релизом 3.7.0 расширения GitLab Workflow изменения мерж-реквеста стали доступны напрямую в VS Code. Это позволяет быстро просматривать изменения в мерж-реквестах ваших проектов.


В рамках работы над добавлением полноценного ревью кода в VS Code следующим шагом мы собираемся добавить комментарии к диффам.


View Merge Request changes in VS Code


Документация по расширению для VS Code и оригинальный тикет.


Улучшенное скачивание артефактов для вложенных конвейеров


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


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


Теперь вы можете использовать новый синтаксис needs:pipeline, чтобы указать вложенному конвейеру, из какого конвейера ему нужно скачивать артефакты. Вы можете использовать его, чтобы скачивать артефакты из родительского конвейера или из другого вложенного конвейера в рамках той же иерархии.


Improved artifact downloads with child pipelines


Документация по скачиванию артефактов для вложенных конвейеров и оригинальный тикет.


Обход ограничений Docker и ускорение конвейеров


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package
Для более быстрых и надёжных сборок вы можете использовать нашу фичу, прокси зависимостей, для кэширования образов контейнеров из Docker Hub. Однако, когда Docker начал применять ограничения по количеству запросов docker pull, вы могли заметить, что даже когда ваш образ скачивался из кэша, Docker всё равно засчитывал его в лимит. Это происходило потому, что прокси зависимостей кэшировал только слои (или блоб-объекты) образа, но не манифест, который содержит информацию о том, как собрать данный образ. Так как манифест был необходим для сборки, всё равно приходилось выполнять pull. А если Docker Hub был недоступен, вы не могли скачать нужный образ.
Начиная с этого релиза прокси зависимостей будет кэшировать и слои, и манифест образа. Так что при первом скачивании с использованием alpine:latest образ будет добавлен в кэш прокси зависимостей, и это будет считаться за один pull. В следующий раз, когда вы будете скачивать alpine:latest, всё будет скачиваться из кэша, даже если Docker Hub недоступен, и это скачивание не будет учитываться в лимите Docker.


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



Документация по прокси зависимостей и оригинальный тикет.


Быстрый поиск и просмотр общих пакетов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package


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


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



Документация по просмотру пакетов и оригинальный тикет.


Прокси зависимостей для приватных проектов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package


Вы можете использовать прокси зависимостей GitLab для проксирования и кэширования образов контейнеров из Docker Hub. До последнего времени эта фича была доступна только для публичных групп, что не позволяло многим пользователям её использовать.


Теперь вы можете использовать прокси зависимостей и для приватных проектов. Вы можете снизить свои скачивания с Docker Hub путём кэширования ваших образов контейнера для использования их в будущем. Так как прокси зависимостей хранит образы Docker в пространстве, связанном с вашей группой, вы должны авторизоваться с вашим логином и паролем GitLab или с личным токеном доступа, для которого есть разрешение как минимум на чтение (read_registry).


Документация по прокси зависимостей и оригинальный тикет.


Улучшенная поддержка анализаторов SAST для нескольких проектов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Secure


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


Документация по поддержке репозиториев для нескольких проектов и оригинальный эпик.


Описание релиза во внешнем файле


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


Если вы создаёте релизы в конвейерах через файл .gitlab-ci.yml вашего проекта, вам, возможно, было сложно поддерживать в актуальном состоянии описание каждого релиза. В релизе GitLab 13.7 вы можете задавать описание вашего релиза в файле с контролем версий или в автоматически генерируемом файле и вызывать его из .gitlab-ci.yml. При этом содержимое файла загружается в описание релиза в формате Markdown. Это упрощает создание, поддержку и использование контроля версий для релизов, а также будет особенно полезно при автогенерации лога изменений. Огромное спасибо Nejc Habjan и Siemens за этот невероятный вклад!



Документация по описаниям релизов и оригинальный тикет.


Поддержка для версий Kubernetes 1.17, 1.18 и 1.19


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure


Поддержка GitLab для последних версий Kubernetes позволяет вам пользоваться преимуществами интеграций GitLab с Kubernetes, такими как GitLab Kubernetes Agent, Auto DevOps и на более поздних кластерах GitLab Managed Apps. В этом релизе GitLab добавил официальную поддержку для версий Kubernetes 1.17, 1.18 и 1.19.


Документация по кластерам и оригинальный тикет.


Geo поддерживает репликацию сниппетов


(PREMIUM, ULTIMATE) Доступность


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


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


Документация по репликации Geo и оригинальный эпик.


Поддержка зашифрованных учётных данных LDAP


(CORE, STARTER, PREMIUM, ULTIMATE) Доступность


GitLab использует единый файл конфигурации, например gitlab.rb в Omnibus GitLab, что упрощает настройку всех связанных сервисов. В этот файл конфигурации включены некоторые секретные ключи, например учётные данные для аутентификации на сервере LDAP. Хотя для доступа к этому файлу требуются специальные права, хорошей практикой считается отделять секретные ключи от конфигурации.


Установки Omnibus GitLab и Source теперь поддерживают зашифрованные учётные данные, причём первыми поддерживаемыми учётными данными стали LDAP. Это снижает уязвимость конфигурационного файла GitLab, а также помогает достичь соответствия требованиям заказчика.


Документация по настройке зашифрованных учётных данных LDAP и оригинальный тикет.


Веб-хуки при добавлении новых участников группы


(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


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


Документация по веб-хукам и оригинальный тикет.


Улучшенная фильтрация и сортировка списков участников группы


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage


Мы продолжили улучшать наш список участников группы и добавили для него новые возможности фильтрации и сортировки. Это поможет администраторам группы быстро находить нужную им информацию. Например, сортировку по последнему времени входа (Last sign-in) можно использовать для поиска пользователей, которые в последнее время не заходили на GitLab, и для помощи в управлении лицензиями.


Improved group members list filtering and sorting


Документация по фильтрации и сортировке участников группы и оригинальный тикет.


Автоматическая подготовка профиля пользователя с SAML


(SILVER, GOLD) Стадия цикла DevOps: Manage


Раньше в качестве одной из частей включения в группу с SAML пользователям нужно было заполнять форму регистрации. В GitLab 13.7 мы представляем синхронизацию пользователей для групп с использованием SAML. Когда пользователь в первый раз входит в группу с SAML, учётная запись пользователя создаётся для него автоматически, если нет существующего пользователя с таким же адресом электронной почты. Автоматическая подготовка с SAML улучшает процесс адаптации новых пользователей и гарантирует, что вновь созданные учётные записи содержат правильную информацию.


Документация по настройке групп с SAML и оригинальный тикет.


Настраиваемый адрес электронной почты для службы поддержки


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan


Раньше вашим пользователям было трудно запомнить (а следовательно, и использовать) адрес электронной почты службы поддержки GitLab. С введением настраиваемого адреса электронной почты теперь можно выбрать суффикс адреса, который имеет смысл для вашей компании и который будет легче запомнить вашим пользователям. Это ещё один шаг, который нужен для того, чтобы вы могли предоставлять своим пользователям качественную поддержку.


Документация по настройке адреса электронной почты для службы поддержки и оригинальный тикет.


Различайте изменения форматирования и правки, сделанные из редактора статических сайтов


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create


Редактор статических сайтов предлагает интуитивно понятный и знакомый всем режим редактирования WYSIWYG для контента Markdown. Чтобы обеспечить единообразный формат вывода Markdown, редактор WYSIWYG автоматически переформатирует содержимое страницы в соответствии с соглашениями о стилях, определёнными в парсере Markdown. Это происходит полностью в фоновом режиме ещё до того, как вы начнёте редактировать. Однако эти изменения форматирования коммитятся вместе с вашими изменениями содержимого. Если страница, которую вы редактируете, не следовала тем же соглашениям о стилях, для проверяющих итогового мерж-реквеста может быть сложно отличить ваши изменения от автоматического форматирования.


Начиная с GitLab 13.7 редактор статических сайтов автоматически исправляет несоответствия в синтаксисе Markdown и коммитит все необходимые изменения форматирования в новой ветке. По завершении редактирования кнопка Опубликовать создаёт отдельный коммит, содержащий только ваши изменения. Это может сэкономить время проверяющим изменения, которые вместо того, чтобы продираться через изменения синтаксиса, смогут сосредоточиться на вашем контенте.


В будущем мы планируем сделать параметры форматирования настраиваемыми, так что следите за новостями в соответствующем тикете.


Документация по редактору статических сайтов и оригинальный тикет.


Предзаполненные переменные при ручном запуске конвейеров


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify


Раньше, когда вы хотели запустить конвейер вручную, вам нужно было узнать нужные переменные, а затем ввести их на странице Запуск конвейера (Run Pipeline). Это может быть утомительно и чревато ошибками, если нужно ввести множество пар ключ-значение. Теперь форма для запуска конвейера будет сгенерирована для вашего конвейера с переменными, предварительно заполненными на основе определений переменных в вашем файле .gitlab-ci.yml, что сделает этот процесс более эффективным.


Pre-filled variables when running pipelines manually


Документация по ручному запуску конвейера и оригинальный тикет.


Собранные с помощью CI/CD пакеты всегда отображают информацию о сборке


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package


Если вы публиковали пакеты в реестре пакетов, то могли заметить, что пакеты, созданные с помощью GitLab CI/CD, не всегда отображали коммит и конвейер, ответственные за создание или обновление вашего пакета. Это могло происходить по нескольким причинам.


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


В дальнейшем любой пакет, собранный или обновлённый с помощью GitLab CI/CD, будет отображать информацию о коммите и конвейере в пользовательском интерфейсе пакетов. Чтобы избежать проблем с производительностью или пользовательским интерфейсом, будут отображаться только пять обновлений пакета. В майлстоуне 13.8 мы создадим дизайн, который поможет вам легко просматривать все данные, включая историю. А пока вы можете использовать API пакетов, чтобы смотреть всю историю сборки данного пакета.


Packages built with CI/CD always display build info


Документация по реестру пакетов и сборке пакетов с помощью GitLab CI/CD и оригинальный тикет.


Используйте предопределённые переменные с прокси зависимостей


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package


С помощью проксирования и кэширования образов контейнеров из Docker Hub прокси зависимостей помогает вам повысить производительность ваших конвейеров. Несмотря на то, что прокси-сервер предназначен для интенсивного использования с CI/CD, для использования этой фичи вам нужно было определить свои собственные переменные или прописать значения в вашем файле gitlab.ci-yml. Это затрудняло начало работы для тех, кто работает один, и не позволяло использовать его в качестве масштабируемого решения, особенно для организаций с множеством различных групп и проектов.


В дальнейшем вы можете использовать предопределённые переменные окружения в качестве интуитивно понятного способа для прокси зависимостей. Поддерживаются следующие переменные:


  • CI_DEPENDENCY_PROXY_USER: пользователь CI для входа в прокси зависимостей,
  • CI_DEPENDENCY_PROXY_PASSWORD: пароль для входа в прокси зависимостей,
  • CI_DEPENDENCY_PROXY_SERVER: сервер для входа в прокси зависимостей,
  • CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX: префикс образа для извлечения образов через прокси зависимостей.

Попробуйте и дайте нам знать, что вы думаете!


Документация по аутентификации в прокси зависимостей с помощью CI/CD и оригинальный тикет.


Результаты сканирований безопасности в виджете мерж-реквеста стали удобнее


(CORE, STARTER, PREMIUM, FREE, BRONZE, SILVER) Стадия цикла DevOps: Secure


С помощью SAST и поиска секретных ключей, которые теперь доступны для всех пользователей, мы упростили жизнь всем пользователям GitLab, взаимодействующим с результатами сканирования безопасности в мерж-реквесте, за счёт облегчения доступа к результатам сканирования безопасности. Ранее результаты сканирования безопасности были доступны только на странице Обзор конвейера, и вы должны были знать, где искать, чтобы найти их там. Теперь все мерж-реквесты будут показывать, были ли для них запущены проверки безопасности, и помогут вам найти артефакты задания. Это изменение не затрагивает работу с мерж-реквестами для пользователей плана Ultimate.


Improved MR experience for security scans


Документация по просмотру результатов сканирования безопасности в мерж-реквесте и оригинальный эпик.


Специальные ссылки на уязвимости


(ULTIMATE, GOLD) Стадия цикла DevOps: Secure


Мы ввели уязвимости как полноценные объекты в 12.10. Будучи объектом, каждая из них имеет уникальный URL-адрес, позволяющий напрямую перейти к деталям любой уязвимости. Несмотря на значительное улучшение видимости и согласованности, ссылки на уязвимости в тикетах и эпиках (в русской локализации GitLab цели) всё равно нужно копировать вручную в виде ссылок Markdown. Это делает неэффективным совместное использование, а ссылки на уязвимости в других областях GitLab более громоздкими, чем для других объектов, например тикетов.


Теперь на уязвимости можно ссылаться с помощью специальных ссылок. На них впервые будет опробован новый синтаксис [object_type:ID], который в конечном итоге распространится на другие существующие ссылки. Теперь вы можете быстро вставить ссылку на уязвимость из любого места, где обычно используется специальная ссылка, например из описания тикета или мерж-реквеста. Просто введите [vulnerability:123] в описании тикета, чтобы вставить ссылку на уязвимость с идентификатором 123 в том же проекте. Вы также можете добавить к идентификатору префикс пространства имён или проекта, чтобы ссылаться на уязвимости вне контекста текущего проекта.


Документация по специальным ссылкам и оригинальный тикет.


Смотрите, какие коммиты и конвейеры выполняются в форке, а какие в родительском проекте


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release


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


В этом релизе вы сможете увидеть, какие коммиты и конвейеры выполнялись в проекте-форке, а какие в родительском проекте. Коммиты в форках отмечены уникальным значком и тултипом, что позволяет вам узнать, что они выполнялись из мерж-реквеста в форке. Это упрощает понимание контекста, в котором работал ваш конвейер, и устраняет необходимость более детально изучать источник.


See which commits and pipelines run in the fork project vs. the parent project


Документация по запуску конвейеров в родительском проекте для мерж-реквестов из проекта-форка и оригинальный тикет.


Запросы к базе данных выполняются быстрее при использовании балансировщика нагрузки


(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Доступность


Многие запросы к базе данных повторяются несколько раз, так что их можно кэшировать для повышения общей производительности. Для GitLab можно кэшировать примерно 10% всех запросов. В GitLab 13.7 мы включили кэширование запросов к базе данных, когда используется балансировка нагрузки базы данных. На GitLab.com это приводит к кэшированию ~700 000 запросов каждую минуту и сокращает среднее время выполнения запросов вплоть до 10%.


Для запросов, которые выполняются более 100 раз, мы уменьшили продолжительность запроса на 11-31% и кэшировали ~30% всех операторов SELECT, которые бы в противном случае выполнялись на реплике базы данных.


Документация по балансировке нагрузки на базу данных и оригинальный тикет.


Для новых установок по умолчанию используется PostgreSQL 12


(CORE, STARTER, PREMIUM, ULTIMATE) Доступность


Начиная с GitLab 13.3 PostgreSQL 12 был доступен в качестве опции как для пакетов Omnibus, так и для нашего Helm chart. PostgreSQL 12 улучшает производительность, а также предлагает значительные преимущества при индексировании и секционировании.


Начиная с GitLab 13.7 новые установки GitLab будут по умолчанию использовать PostgreSQL 12. Чтобы выполнить обновление вручную, запустите gitlab-ctl pg-upgrade.


Многонодовые инстансы базы данных должны будут переключиться с repmgr на Patroni до обновления с помощью Patroni. Затем можно обновить и повторно синхронизировать вторичные ноды Geo.


Документация по настройкам баз данных в GitLab 13.3 и более поздних версиях и оригинальный тикет.




Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте: GitLab 13.7 released with merge request reviewers and automatic rollback upon failure.


Над переводом с английского работали cattidourden, maryartkey, ainoneko и rishavant.

Подробнее..

Ваш безлимит как увеличить пропускную способность автомерджа

21.06.2021 14:12:41 | Автор: admin

Отыщи всему начало, и ты многое поймёшь (Козьма Прутков).

Меня зовут Руслан, я релиз-инженер в Badoo и Bumble. Недавно я столкнулся с необходимостью оптимизировать механизм автомерджа в мобильных проектах. Задача оказалась интересной, поэтому я решил поделиться её решением с вами. В статье я расскажу, как у нас раньше было реализовано автоматическое слияние веток Git и как потом мы увеличили пропускную способность автомерджа и сохранили надёжность процессов на прежнем высоком уровне.

Свой автомердж

Многие программисты ежедневно запускают git merge, разрешают конфликты и проверяют свои действия тестами. Кто-то автоматизирует сборки, чтобы они запускались автоматически на отдельном сервере. Но решать, какие ветки сливать, всё равно приходится человеку. Кто-то идёт дальше и добавляет автоматическое слияние изменений, получая систему непрерывной интеграции (Continuous Integration, или CI).

Например, GitHub предлагает полуручной режим, при котором пользователь с правом делать записи в репозиторий может поставить флажок Allow auto-merge (Разрешить автомердж). При соблюдении условий, заданных в настройках, ветка будет соединена с целевой веткой. Bitbucket поддерживает большую степень автоматизации, накладывая при этом существенные ограничения на модель ветвления, имена веток и на количество мерджей.

Такой автоматизации может быть достаточно для небольших проектов. Но с увеличением количества разработчиков и веток, ограничения, накладываемые сервисами, могут существенно повлиять на производительность CI. Например, раньше у нас была система мерджа, при которой основная ветка всегда находилась в стабильном состоянии благодаря последовательной стратегии слияний. Обязательным условием слияния была успешная сборка при наличии всех коммитов основной ветки в ветке разработчика. Работает эта стратегия надёжно, но у неё есть предел, определяемый временем сборки. И этого предела оказалось недостаточно. При времени сборки в 30 минут на обработку 100 слияний в день потребовалось бы более двух суток. Чтобы исключить ограничения подобного рода и получить максимальную свободу выбора стратегий мерджа и моделей ветвления, мы создали собственный автомердж.

Итак, у нас есть свой автомердж, который мы адаптируем под нужды каждой команды. Давайте рассмотрим реализацию одной из наиболее интересных схем, которую используют наши команды Android и iOS.

Термины

Main. Так я буду ссылаться на основную ветку репозитория Git. И коротко, и безопасно. =)

Сборка. Под этим будем иметь в виду сборку в TeamCity, ассоциированную с веткой Git и тикетом в трекере Jira. В ней выполняются как минимум статический анализ, компиляция и тестирование. Удачная сборка на последней ревизии ветки в сочетании со статусом тикета To Merge это однo из необходимых условий автомерджа.

Пример модели ветвления

Испробовав разные модели ветвления в мобильных проектах, мы пришли к следующему упрощённому варианту:

На основе ветки main разработчик создаёт ветку с названием, включающим идентификатор тикета в трекере, например PRJ-k. По завершении работы над тикетом разработчик переводит его в статус Resolved. При помощи хуков, встроенных в трекер, мы запускаем для ветки тикета сборку. В определённый момент, когда изменения прошли ревью и необходимые проверки автотестами на разных уровнях, тикет получает статус To Merge, его забирает автоматика и отправляет в main.

Раз в неделю на основе main мы создаём ветку релиза release_x.y.z, запускаем на ней финальные сборки, при необходимости исправляем ошибки и наконец выкладываем результат сборки релиза в App Store или Google Play. Все фазы веток отражаются в статусах и дополнительных полях тикетов Jira. В общении с Jira помогает наш клиент REST API.

Такая простая модель не только позволила нам построить надёжный автомердж, но и оказалась удобной для всех участников процесса. Однако сама реализация автомерджа менялась несколько раз, прежде чем мы добились высокой производительности и минимизировали количество побочных эффектов: конфликтов, переоткрытий тикетов и ненужных пересборок.

Первая версия: жадная стратегия

Сначала мы шли от простого и очевидного. Брали все тикеты, находящиеся в статусе To Merge, выбирали из них те, для которых есть успешные сборки, и отправляли их в main командой git merge, по одной.

Примечание: я немного упростил описание первой версии. В реальности между main и ветками разработчиков была ветка dev, где и происходили все проблемы, описанные выше. Перед слиянием main с dev мы добивались стабилизации сборок при помощи специальных веток интеграции, создававшихся автоматически на основе dev с периодом в сутки.

Наличие в TeamCity актуальной успешной сборки мы проверяли при помощи метода REST API getAllBuilds примерно следующим образом (псевдокод):

haveFailed = False # Есть ли неудачные сборкиhaveActive = False # Есть ли активные сборки# Получаем сборки типа buildType для коммита commit ветки branchbuilds = teamCity.getAllBuilds(buildType, branch, commit)# Проверяем каждую сборкуfor build in builds:  # Проверяем каждую ревизию в сборке  for revision in build.revisions:    if revision.branch is branch and revision.commit is commit:      # Сборка актуальна      if build.isSuccessful:        # Сборка актуальна и успешна        return True      else if build.isRunning or build.isQueued        haveActive = True      else if build.isFailed:        haveFailed = Trueif haveFailed:  # Исключаем тикет из очереди, переоткрывая его  ticket = Jira.getTicket(branch.ticketKey)  ticket.reopen("Build Failed")  return Falseif not haveActiveBuilds:  # Нет ни активных, ни упавших, ни удачных сборок. Запускаем новую  TriggerBuild(buildType, branch)

Ревизии это коммиты, на основе которых TeamCity выполняет сборку. Они отображаются в виде 16-ричных последовательностей на вкладке Changes (Изменения) страницы сборки в веб-интерфейсе TeamCity. Благодаря ревизиям мы можем легко определить, требуется ли пересборка ветки тикета или тикет готов к слиянию.

Важно, что ревизию можно (а часто даже необходимо) указывать в запросе на добавление новой сборки в очередь в параметре lastChanges, потому что в противном случае TeamCity может выбрать устаревшую ревизию ветки при запуске сборки. Как будет показано ниже, указывать ревизию необходимо в тех случаях, если, например, логика вне TeamCity основана на поиске сборок на конкретных коммитах (наш случай).

Так как после перевода тикета в статус готовности (в нашем примере Resolved) соответствующая ветка, как правило, не меняется, то и сборка, ассоциированная с тикетом, чаще всего остаётся актуальной. Кроме того, сам факт нахождения тикета в статусе To Merge говорит о высокой вероятности того, что сборка не упала. Ведь при падении сборки мы сразу переоткрываем тикет.

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

Всё работало быстро, но требовало внимания. То и дело возникали ситуации, когда изменения нескольких тикетов конфликтовали между собой. Конфликты при слияниях как явление достаточно распространённое поначалу ни у кого особых вопросов не вызывали. Их разрешали разработчики, дежурные по релизу. Но с увеличением количества разработчиков, задач и, соответственно, веток, приведение релиза в порядок требовало всё больше усилий. Задержки в разрешении конфликтов начали сказываться на новых задачах. Полагаю, не стоит продолжать эту цепочку скорее всего, вы уже поняли, что я имею в виду. С конфликтами нужно было что-то делать, причём не допуская их попадания в релиз.

Конфликты слияния

Если изменить одну и ту же строку кода в разных ветках и попытаться соединить их в main, то Git попросит разрешить конфликты слияния. Из двух вариантов нужно выбрать один и закоммитить изменения.

Это должно быть знакомо практически каждому пользователю системы контроля версий (VCS). Процессу CI, так же, как и любому пользователю VCS, нужно разрешать конфликты. Правда, делать это приходится немного вслепую, в условиях почти полного непонимания кодовой базы.

Если команда git merge завершилась с ошибкой и для всех файлов в списке git ls-files --unmerged заданы обработчики конфликтов, то для каждого такого файла мы выполняем парсинг содержимого по маркерам конфликтов <<<<<<<, ======= и >>>>>>>. Если конфликты вызваны только изменением версии приложения, то, например, выбираем последнюю версию между локальной и удалённой частями конфликта.

Конфликт слияния это один из простейших типов конфликтов в CI. При конфликте с main CI обязан уведомить разработчика о проблеме, а также исключить ветку из следующих циклов автомерджа до тех пор, пока в ней не появятся новые коммиты.

Решение следующее: нарушаем как минимум одно из необходимых условий слияния. Так как ветка ассоциирована с тикетом трекера, можно переоткрыть тикет, изменив его статус. Таким образом мы одновременно исключим тикет из автомерджа и оповестим об этом разработчика (ведь он подписан на изменения в тикете). На всякий случай мы отправляем ещё и сообщение в мессенджере.

Логические конфликты

А может ли случиться так, что, несмотря на успешность сборок пары веток в отдельности, после слияния их с main сборка на основной ветке упадёт? Практика показывает, что может. Например, если сумма a и b в каждой из двух веток не превышает 5, то это не гарантирует того, что совокупные изменения a и b в этих ветках не приведут к большей сумме.

Попробуем воспроизвести это на примере Bash-скрипта test.sh:

#!/bin/bashget_a() {    printf '%d\n' 1}get_b() {    printf '%d\n' 2}check_limit() {    local -i value="$1"    local -i limit="$2"    if (( value > limit )); then        printf >&2 '%d > %d%s\n' "$value" "$limit"        exit 1    fi}limit=5a=$(get_a)b=$(get_b)sum=$(( a + b ))check_limit "$a" "$limit"check_limit "$b" "$limit"check_limit "$sum" "$limit"printf 'OK\n'

Закоммитим его и создадим пару веток: a и b.
Пусть в первой ветке функция get_a() вернёт 3, а во второй get_b() вернёт 4:

diff --git a/test.sh b/test.shindex f118d07..39d3b53 100644--- a/test.sh+++ b/test.sh@@ -1,7 +1,7 @@ #!/bin/bash get_a() {-    printf '%d\n' 1+    printf '%d\n' 3 } get_b() {git diff main bdiff --git a/test.sh b/test.shindex f118d07..0bd80bb 100644--- a/test.sh+++ b/test.sh@@ -5,7 +5,7 @@ get_a() { }  get_b() {-    printf '%d\n' 2+    printf '%d\n' 4 }  check_limit() {

В обоих случаях сумма не превышает 5 и наш тест проходит успешно:

git checkout a && bash test.shSwitched to branch 'a'OKgit checkout b && bash test.shSwitched to branch 'b'OK

Но после слияния main с ветками тесты перестают проходить, несмотря на отсутствие явных конфликтов:

git merge a bFast-forwarding to: aTrying simple merge with bSimple merge did not work, trying automatic merge.Auto-merging test.shMerge made by the 'octopus' strategy. test.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)bash test.sh7 > 5

Было бы проще, если бы вместо get_a() и get_b() использовались присваивания: a=1; b=2, заметит внимательный читатель и будет прав. Да, так было бы проще. Но, вероятно, именно поэтому встроенный алгоритм автомерджа Git успешно обнаружил бы конфликтную ситуацию (что не позволило бы продемонстрировать проблему логического конфликта):

git merge a Updating 4d4f90e..8b55df0Fast-forward test.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)git merge b Auto-merging test.shCONFLICT (content): Merge conflict in test.shRecorded preimage for 'test.sh'Automatic merge failed; fix conflicts and then commit the result.

Разумеется, на практике конфликты бывают менее явными. Например, разные ветки могут полагаться на API разных версий какой-нибудь библиотеки зависимости, притом что более новая версия не поддерживает обратной совместимости. Без глубоких знаний кодовой базы (читай: без разработчиков проекта) обойтись вряд ли получится. Но ведь CI как раз и нужен для решения таких проблем.

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

Превентивные меры

Итак, главное не допустить попадания логического конфликта в main. Иначе придётся долго и мучительно искать источник ошибок, а затем программиста, который проблему должен или может решить. Причём делать это нужно максимально быстро и качественно, чтобы, во-первых, не допустить задержки релиза и во-вторых, избежать в новых ветках логических конфликтов, основанных на уже выявленном конфликте. Такие конфликты часто приводят к неработоспособности большой части приложения или вовсе блокируют его запуск.

Нужно синхронизировать ветки так, чтобы их совокупный вклад в main не приводил к падению сборки релиза. Ясно, что все готовые к слиянию ветки нужно так или иначе объединить и прогнать тесты по результату объединения. Путей решения много, давайте посмотрим, каким был наш путь.

Вторая версия: последовательная стратегия

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

Git, по идее, как раз и является средством синхронизации. Но порядок попадания веток в main и, наоборот, main в ветки определяем мы сами. Чтобы определить точно, какие из веток вызывают проблемы в main, можно попробовать отправлять их туда по одной. Тогда можно выстроить их в очередь, а порядок организовать на основе времени попадания тикета в статус To Merge в стиле первый пришёл первым обслужен.

С порядком определились. А как дальше соединять ветки? Допустим, мы сольём в main первый тикет из очереди. Так как main изменилась, она может конфликтовать с остальными тикетами в очереди. Поэтому перед тем как сливать следующий тикет, нужно удостовериться, что обновлённая main по-прежнему совместима с ним. Для этого достаточно слить main в тикет. Но так как после соединения main с веткой её состояние отличается от того, которое было в сборке, необходимо перезапустить сборку. Для сохранения порядка все остальные тикеты в очереди должны ждать завершения сборки и обработки впередистоящих тикетов. Примерно такие рассуждения привели нас к последовательной стратегии автомерджа.

Работает схема надёжно и предсказуемо. Благодаря обязательной синхронизации с main и последующей пересборке конфликты между ветками удаётся выявлять сразу, до попадания их в main. Раньше же нам приходилось разрешать конфликт уже после слияния релиза со множеством веток, большая часть из которых к этому конфликту отношения не имела. Кроме того, предсказуемость алгоритма позволила нам показать очередь тикетов в веб-интерфейсе, чтобы можно было примерно оценить скорость попадания их веток в main.

Но есть у этой схемы существенный недостаток: пропускная способность автомерджа линейно зависит от времени сборки. При среднем времени сборки iOS-приложения в 25 минут мы можем рассчитывать на прохождение максимум 57 тикетов в сутки. В случае же с Android-приложением требуется примерно 45 минут, что ограничивает автомердж 32 тикетами в сутки, а это даже меньше количества Android-разработчиков в нашей компании.

На практике время ожидания тикета в статусе To Merge составляло в среднем 2 часа 40 минут со всплесками, доходящими до 10 часов! Необходимость оптимизации стала очевидной. Нужно было увеличить скорость слияний, сохранив при этом стабильность последовательной стратегии.

Финальная версия: сочетание последовательной и жадной стратегий

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

Давайте вспомним идею жадной стратегии: мы сливали все ветки готовых тикетов в main. Основной проблемой было отсутствие синхронизации между ветками. Решив её, мы получим быстрый и надёжный автомердж!

Раз нужно оценить общий вклад всех тикетов в статусе To Merge в main, то почему бы не слить все ветки в некоторую промежуточную ветку Main Candidate (MC) и не запустить сборку на ней? Если сборка окажется успешной, то можно смело сливать MC в main. В противном случае придётся исключать часть тикетов из MC и запускать сборку заново.

Как понять, какие тикеты исключить? Допустим, у нас n тикетов. На практике причиной падения сборки чаще всего является один тикет. Где он находится, мы не знаем все позиции от 1 до n являются равноценными. Поэтому для поиска проблемного тикета мы делим n пополам.

Так как место тикета в очереди определяется временем его попадания в статус To Merge, имеет смысл брать ту половину, в которой расположены тикеты с большим временем ожидания.

Следуя этому алгоритму, для k проблемных тикетов в худшем случае нам придётся выполнить O(k*log2(n)) сборок, прежде чем мы обработаем все проблемные тикеты и получим удачную сборку на оставшихся.

Вероятность благоприятного исхода велика. А ещё в то время, пока сборки на ветке MC падают, мы можем продолжать работу при помощи последовательного алгоритма!

Итак, у нас есть две автономные модели автомерджа: последовательная (назовём её Sequential Merge, или SM) и жадная (назовём её Greedy Merge, или GM). Чтобы получить пользу от обеих, нужно дать им возможность работать параллельно. А параллельные процессы требуют синхронизации, которой можно добиться либо средствами межпроцессного взаимодействия, либо неблокирующей синхронизацией, либо сочетанием этих двух методов. Во всяком случае, мне другие методы неизвестны.

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

Остаётся предотвратить все возможные случаи состояний гонки. Их много, но для понимания сути приведу несколько самых важных:

  1. SM-SM и GM-GM: между командами одного типа.

  2. SM-GM: между SM и GM в рамках одного репозитория.

Первая проблема легко решается при помощи мьютекса по токену, включающему в себя имя команды и название репозитория. Пример: lock_${command}_${repository}.

Поясню, в чём заключается сложность второго случая. Если SM и GM будут действовать несогласованно, то может случиться так, что SM соединит main с первым тикетом из очереди, а GM этого тикета не заметит, то есть соберёт все остальные тикеты без учёта первого. Например, если SM переведёт тикет в статус In Master, а GM будет всегда выбирать тикеты по статусу To Merge, то GM может никогда не обработать тикета, соединённого SM. При этом тот самый первый тикет может конфликтовать как минимум с одним из других.

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

Таким образом, мы получили своего рода неблокирующую синхронизацию.

Немного о TeamCity

В процессе реализации GM нам предстояло обработать много нюансов, которыми я не хочу перегружать статью. Но один из них заслуживает внимания. В ходе разработки я столкнулся с проблемой зацикливания команды GM: процесс постоянно пересобирал ветку MC и создавал новую сборку в TeamCity. Проблема оказалась в том, что TeamCity не успел скачать обновления репозитория, в которых была ветка MC, созданная процессом GM несколько секунд назад. К слову, интервал обновления репозитория в TeamCity у нас составляет примерно 30 секунд.

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

Кто-то посчитает решение очевидным, но я нашёл его не сразу. Оказывается, прикрепить ревизию к сборке при её добавлении в очередь можно при помощи параметра lastChanges метода addBuildToQueue:

<lastChanges>  <change    locator="version:{{revision}},buildType:(id:{{build_type}})"/></lastChanges>

В этом примере {{revision}} заменяется на 16-ричную последовательность коммита, а {{build_type}} на идентификатор конфигурации сборки. Но этого недостаточно, так как TeamCity, не имея информации о новом коммите, может отказать нам в запросе.

Для того чтобы новый коммит дошёл до TeamCity, нужно либо подождать примерно столько, сколько указано в настройках конфигурации корня VCS, либо попросить TeamCity проверить наличие изменений в репозитории (Pending Changes) при помощи метода requestPendingChangesCheck, а затем подождать, пока TeamCity скачает изменения, содержащие наш коммит. Проверка такого рода выполняется посредством метода getChange, где в changeLocator нужно передать как минимум сам коммит в качестве параметра локатора version. Кстати, на момент написания статьи (и кода) на странице ChangeLocator в официальной документации описание параметра version отсутствовало. Быть может, поэтому я не сразу узнал о его существовании и о том, что это 40-символьный 16-ричный хеш коммита.

Псевдокод:

teamCity.requestPendingChanges(buildType)attempt = 1while attempt <= 20:  response = teamCity.getChange(commit, buildType)  if response.commit == commit:    return True # Дождались  sleep(10)return False

О предельно высокой скорости слияний

У жадной стратегии есть недостаток на поиск ветки с ошибкой может потребоваться много времени. Например, 6 сборок для 20 тикетов у нас может занять около трёх часов. Можно ли устранить этот недостаток?

Допустим, в очереди находится 10 тикетов, среди которых только 6-й приводит к падению сборки.

Согласно жадной стратегии, мы пробуем собрать сразу все 10 тикетов, что приводит к падению сборки. Далее собираем левую половину (с 1 по 5) успешно, так как тикет с ошибкой остался в правой половине.

Если бы мы сразу запустили сборку на левой половине очереди, то не потеряли бы времени. А если бы проблемным оказался не 6-й тикет, а 4-й, то было бы выгодно запустить сборку на четверти длины всей очереди, то есть на тикетах с 1 по 3, например.

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

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

Примерно такой же алгоритм реализован в премиум-функции GitLab под названием Merge Trains. Перевода этого названия на русский язык я не нашёл, поэтому назову его Поезда слияний. Поезд представляет собой очередь запросов на слияние с основной веткой (merge requests). Для каждого такого запроса выполняется слияние изменений ветки самого запроса с изменениями всех запросов, расположенных перед ним (то есть запросов, добавленных в поезд ранее). Например, для трёх запросов на слияние A, B и С GitLab создаёт следующие сборки:

  1. Изменения из А, соединённые с основной веткой.

  2. Изменения из A и B, соединённые с основной веткой.

  3. Изменения из A, B и C, соединённые с основной веткой.

Если сборка падает, то соответствующий запрос из очереди удаляется, а сборки всех предыдущих запросов перезапускаются (без учёта удалённого запроса).

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

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

Но если преград человеческой мысли нет, то пределы аппаратных ресурсов видны достаточно отчётливо:

  1. Каждой сборке нужен свой агент в TeamCity.

  2. В нашем случае у сборки мобильного приложения есть порядка 15-100 сборок-зависимостей, каждой из которых нужно выделить по агенту.

  3. Сборки автомерджа мобильных приложений в main составляют лишь малую часть от общего количества сборок в TeamCity.

Взвесив все плюсы и минусы, мы решили пока остановиться на алгоритме SM + GM. При текущей скорости роста очереди тикетов алгоритм показывает хорошие результаты. Если в будущем заметим возможные проблемы с пропускной способностью, то, вероятно, пойдём в сторону Merge Trains и добавим пару параллельных сборок GM:

  1. Вся очередь.

  2. Левая половина очереди.

  3. Левая четверть очереди.

Что в итоге получилось

В результате применения комбинированной стратегии автомерджа нам удалось добиться следующего:

  • уменьшение среднего размера очереди в 2-3 раза;

  • уменьшение среднего времени ожидания в 4-5 раз;

  • мердж порядка 50 веток в день в каждом из упомянутых проектов;

  • увеличение пропускной способности автомерджа при сохранении высокого уровня надёжности, то есть мы практически сняли ограничение на количество тикетов в сутки.

Примеры графиков слияний за несколько дней:

Количество тикетов в очереди до и после внедрения нового алгоритма:

Среднее количество тикетов в очереди (AVG) уменьшилось в 2,5 раза (3,95/1,55).

Время ожидания тикетов в минутах:

Среднее время ожидания (AVG) уменьшилось в 4,4 раза (155,5/35,07).

Подробнее..

Что такое VCS (система контроля версий)

17.04.2021 00:07:00 | Автор: admin

Система контроля версий (от англ. Version Control System, VCS) это место хранения кода. Как dropbox, только для разработчиков!

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

А потом я подробнее расскажу, как VCS работает что значит "создать репозиторий", "закоммитить и смерджить изменения", и другие страшные слова. В конце мы пощупаем одну из систем VCS руками, скачаем код из открытого репозитория.

Итого содержание:

Что это такое и зачем она нужна

Допустим, что мы делаем калькулятор на Java (язык программирования). У нас есть несколько разработчиков Вася, Петя и Иван. Через неделю нужно показывать результат заказчику, так что распределяем работу:

  • Вася делает сложение;

  • Петя вычитание;

  • Иван начинает умножение, но оно сложное, поэтому переедет в следующий релиз.

Исходный код калькулятора хранится в обычной папке на сетевом диске, к которому все трое имеют доступ. Разработчик копирует этот код к себе на машину, вносит изменения и проверяет. Если всё хорошо кладет обратно. Так что код в общей папке всегда рабочий!

Итак, все забрали себе файлы из общей папки. Пока их немного:

  • Main.java общая логика

  • GUI.java графический интерфейс программы

С ними каждый и будет работать!

Вася закончил работу первым, проверил на своей машине все работает, отлично! Удовлетворенно вздохнув, он выкладывает свой код в общую папку. Вася сделал отдельный класс на сложение (Sum.java), добавил кнопку в графический интерфейс (внес изменения в GUI.java) и прописал работу кнопки в Main.java.

Петя химичил-химичил, ускорял работу, оптимизировал... Но вот и он удовлетворенно вздохнул готово! Перепроверил ещё раз работает! Он копирует файлы со своей машины в общую директорию. Он тоже сделал отдельный класс для новой функции (вычитание Minus.java), внес изменения в Main.java и добавил кнопку в GUI.java.

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

Все довольны, Вася с Петей обсуждают планы на следующий релиз. Но тут с показа продукта возвращается расстроенная Катя, менеджер продукта.

Катя, что случилось??

Вы же сказали, что всё сделали! А в графическом интерфейсе есть только вычитание. Сложения нет!

Вася удивился:

Как это нет? Я же добавлял!

Стали разбираться. Оказалось, что Петин файл затер изменения Васи в файлах, которые меняли оба: Main.java и GUI.java. Ведь ребята одновременно взяли исходные файлы к себе на компьютеры у обоих была версия БЕЗ новых функций.

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

Поэтому, когда он положил документы в хранилище, Васины правки были стерты. Остался только новый файл Sum.java, ведь его Петя не трогал.

Хорошо хоть логика распределена! Если бы всё лежало в одном классе, было бы намного сложнее совместить правки Васи и Пети. А так достаточно было немного подправить файлы Main.java и GUI.java, вернув туда обработку кнопки. Ребята быстро справились с этим, а потом убедились, что в общем папке теперь лежит правильная версия кода.

Собрали митинг (жаргон собрание, чтобы обсудить что-то):

Как нам не допустить таких косяков в дальнейшем?

Давайте перед тем, как сохранять файлы в хранилище, забирать оттуда последние версии! А ещё можно брать свежую версию с утра. Например, в 9 часов. А перед сохранением проверять дату изменения. Если она позже 9 утра, значит, нужно забрать измененный файл.

Да, давайте попробуем!

Вася с Петей были довольны, ведь решение проблемы найдено! И только Иван грустит. Ведь он целую неделю работал с кодом, а теперь ему надо было синхронизировать версии... То есть объединять свои правки с изменениями коллег.

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

Когда он пришел с утра, в офисе был переполох. Вася бегал по офису и причитал:

Мои изменения пропали!!! А я их не сохранил!

Увидев Ваню, он подскочил к нему и затряс за грудки:

Зачем ты стер мой код??

Стали разбираться. Оказалось что Вася вчера закончил свой кусок работы, проверил, что обновлений файлов не было, и просто переместил файлы со своего компьютера в общую папку. Не скопировал, а переместил. Копий никаких не осталось.

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

Код теперь не работает! Ты вообще проверял приложение, закончив синхронизацию?

Нет, я только свою часть посмотрел...

Вася покачал головой:

Но ведь при сохранении на общий диск можно допустить ошибку! По самым разным причинам:

  • Разработчик начинающий, чаще допускает ошибки.

  • Случайно что-то пропустил если нужно объединить много файлов, что-то обязательно пропустишь.

  • Посчитал, что этот код не нужен что он устарел или что твоя новая логика делает то же самое, а на самом деле не совсем.

И тогда приложение вообще перестанет работать. Как у нас сейчас.

Ваня задумался:

Хм... Да, пожалуй, ты прав. Нужно тестировать итоговый вариант!

Петя добавил:

И сохранять версии. Может, перенесем наш код в Dropbox, чтобы не терять изменения?

На том и порешили. Остаток дня все трое работали над тем, чтобы приложение снова заработало. После чего бережно перенесли код в дропбокс. Теперь по крайней мере сохранялись старые версии. И, если разработчик криво синхронизировал файлы или просто залил свои, затерев чужие изменения, можно было найти старую версию и восстановить ее.

Через пару дней ребята снова собрали митинг:

Ну как вам в дропбоксе?

Уже лучше. По крайней мере, не потеряем правки!

Петя расстроенно пожимает плечами:

Да, только мы с Васей одновременно вносили изменения в Main.java, создалась конфликтующая версия. И пришлось вручную их объединять... А класс то уже подрос! И глазками сравнивать 100 строк очень невесело... Всегда есть шанс допустить ошибку.

Ну, можно же подойти к тому, кто создал конфликт и уточнить у него, что он менял.

Хорошая идея, давайте попробуем!

Попробовали. Через несколько дней снова митинг:

Как дела?

Да всё зашибись, работаем!

А почему код из дропбокса не работает?

Как не работает??? Мы вчера с Васей синхронизировались!

А ты попробуй его запустить.

Посмотрели все вместе и правда не работает. Какая-то ошибка в Main.java. Стали разбираться:

Так, тут не хватает обработки исключения.

Ой, подождите, я же её добавлял!

Но ты мне не говорил о ней, когда мы объединяли правки.

Да? Наверное, забыл...

Может, еще что забыл? Ну уж давай лучше проверим глазами...

Посидели, выверили конфликтные версии. Потратили час времени всей команды из-за пустяка. Обидно!

Слушайте, может, это можно как-то попроще делать, а? Чтобы человека не спрашивать что ты менял?

Можно использовать программу сравнения файлов. Я вроде слышал о таких. AraxisMerge, например!

Ой, точно! В IDEA же можно сравнивать твой код с клипбордом (сохраненным в Ctrl + C значении). Давайте использовать его!

Точно!

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

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

Да? И что за программы?

Системы контроля версий называются. Вот SVN, например. Давайте попробуем его?

А давайте!

Попробовали. Работает! Еще и часть правок сама синхронизирует, даже если Вася с Петей снова не поделили один файл. Как она это делает? Давайте разбираться!

Как VCS работает

Подготовительная работа

Это те действия, которые нужно сделать один раз.

1. Создать репозиторий

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

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

А потом Вася берет код из дропбокса, и кладет его в VCS специальной командой. В разных системах контроля версии разные названия у команды, но суть одна создать репозиторий, в котором будет храниться код.

Всё! Теперь у нас есть общее хранилище данных! С ним дальше и будем работать.

2. Скачать проект из репозитория

Теперь команде нужно получить проект из репозитория. Можно, конечно, и из дропбокса скачать, пока там актуальная версия, но давайте уже жить по-правильному!

Поэтому Петя, Вася и Иван удаляют то, что было у них было на локальных компьютерах. И забирают данные из репозитория, клонируя его. В Mercurial (один из вариантов VCS) эта команда так и называется clone. В других системах она зовется иначе, но смысл всё тот же клонировать (копировать) то, что лежит в репозитории, к себе на компьютер!

Забрать код таким образом нужно ровно один раз, если у тебя его ещё не было. Дальше будут использоваться другие команды для передачи данных туда-сюда.

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

Ежедневная работа

А это те действия, которые вы будете использовать часто.

1. Обновить проект, забрать последнюю версию из репозитория

Приходя утром на работу, нужно обновить проект на своем компьютере. Вдруг после твоего ухода кто-то вносил изменения?

Так, Вася обновил проект утром и увидел, что Ваня изменил файлы Main.java и GUI.java. Отлично, теперь у Васи актуальная версия на машине. Можно приступать к работе!

В SVN команда обновления называется update, в Mercurial pull. Она сверяет код на твоем компьютере с кодом в репозитории. Если в репозитории появились новые файлы, она их скачает. Если какие-то файлы были удалены удалит и с твоей машины тоже. А если что-то менялось, обновит код на локальном компьютере.

Тут может возникнуть вопрос в чем отличие от clone? Можно же просто клонировать проект каждый раз, да и всё! Зачем отдельная команда?

Клонирование репозитория производится с нуля. А когда разработчики работают с кодом, у них обычно есть какие-то локальные изменения. Когда начал работу, но ещё не закончил. Но при этом хочешь обновить проект, чтобы конфликтов было меньше.

Если бы использовалось клонирование, то пришлось бы переносить все свои изменения в новый репозиторий вручную. А это совсем не то, что нам нужно. Обновление не затронет новые файлы, которые есть только у вас на компьютере.

А еще обновление это быстрее. Обновиться могли 5 файликов из 1000, зачем выкачивать всё?

2. Внести изменения в репозиторий

Вася работает над улучшением сложения. Он придумал, как ускорить его работу. А заодно, раз уж взялся за рефакторинг (жаргон улучшение системы, от англ. refactor), обновил и основной класс Main.java.

Перед началом работы он обновил проект на локальном (своём) компьютере, забрав из репозитория актуальные версии. А теперь готов сохранить в репозиторий свои изменения. Это делается одной или двумя командами зависит от той VCS, которую вы используете в работе.

1 команда commit

Пример системы SVN.

Сделав изменения, Вася коммитит их. Вводит команду commit и все изменения улетают на сервер. Всё просто и удобно.

2 команды commit + push

Примеры системы Mercurial, Git.

Сделав изменения, Вася коммитит их. Вводит команду commit изменения сохранены как коммит. Но на сервер они НЕ уходят!

Чтобы изменения пошли на сервер, их надо запушить. То есть ввести команду push.

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

При этом держать изменения локально тоже не слишком удобно. Поэтому можно спокойно делать коммиты, а потом уже пушить, когда готов. Или когда интернет появился =) Для коммитов он не нужен.

Итого

Когда разработчик сохраняет код в общем хранилище, он говорит:

Закоммитил.

Или:

Запушил.

Смотря в какой системе он работает. После этих слов вы уверены код изменен, можно обновить его на своей машине и тестировать!

3. Разрешить конфликты (merge)

Вася добавил вычисление процентов, а Петя деление. Перед работой они обновили свои локальные сборки, получив с сервера версию 3 файлов Main.java и Gui.java.

Для простоты восприятия нарисуем в репозитории только эти файлы и Minus.java, чтобы показать тот код, который ребята трогать не будут.

Вася закончил первым. Проверив свой код, он отправил изменения на сервер. Он:

  • Добавил новый файл Percent.java

  • Обновил Main.java (версию 3)

  • Обновил Gui.java (версию 3)

При отправке на сервер были созданы версии:

  • Percent.java версия 1

  • Main.java версия 4

  • Gui.java версия 4

Петя закончил чуть позже. Он:

  • Добавил новый файл Division.java

  • Обновил Main.java (версию 3, ведь они с Васей скачивали файлы одновременно)

  • Обновил Gui.java (версию 3)

Готово, можно коммитить! При отправке на сервер были созданы версии:

  • Division.java версия 1

  • Main.java версия 4

  • Gui.java версия 4

Но стойте, Петя обновляет файлы, которые были изменены с момента обновления кода на локальной машине! Конфликт!

Часть конфликтов система может решить сама, ей достаточно лишь сказать merge. И в данном случае этого будет достаточно, ведь ребята писали совершенно разный код, а в Main.java и Gui.java добавляли новые строчки, не трогая старые. Они никак не пересекаются по своим правкам. Поэтому система сливает изменения добавляет в версию 4 Петины строчки.

Но что делать, если они изменяли один и тот же код? Такой конфликт может решить только человек. Система контроля версий подсвечивает Пете Васины правки и он должен принять решение, что делать дальше. Система предлагает несколько вариантов:

  • Оставить Васин код, затерев Петины правки если Петя посмотрит Васны изменения и поймет, что те лучше

  • Затереть Васины правки, взяв версию Петра если он посчитает, что сам все учел

  • Самому разобраться в таком случае в файл кода добавляются обе версии и надо вручную слепить из них итоговый кусок кода

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

Но, разумеется, конфликты все равно бывают. Разработчики делают сложные задачи, на которые уходит день-два. Они затрагивают одни и те же файлы. В итоге, вливая свои изменения в репозиторий, они получают кучу конфликтов, и нужно просмотреть каждый правильно ли система объединила файлы? Не нужно ли ручное вмешательство?

Особая боль глобальный рефакторинг, когда затрагивается МНОГО файлов. Обновление версии библиотеки, переезд с ant на gradle, или просто выкашивание легаси кода. Нельзя коммитить его по кусочкам, иначе у всей команды развалится сборка.

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

А что делать? Обновляет проект и решает конфликты. Иногда в работе над большой задачей разработчик каждый день обновляется и мерджит изменения, а иногда только через несколько дней.

Тестировщик будет сильно реже попадать в конфликтные ситуации, просто потому, что пишет меньше кода. Иногда вообще не пишет, иногда пополняет автотесты. Но с разработкой при этом почти не пересекается. Однако выучить merge все равно придется, пригодится!

4. Создать бранч (ветку)

На следующей неделе нужно показывать проект заказчику. Сейчас он отлично работает, но разработчики уже работают над новыми изменениями. Как быть? Ребята собираются на митинг:

Что делать будем? Не коммитить до показа?

У меня уже готовы новые изменения. Давайте закоммичу, я точно ничего не сломал.

Катя хватается за голову:

Ой, давайте без этого, а? Мне потом опять краснеть перед заказчиками!

Тут вмешивается Иван:

А давайте бранчеваться!

Все оглянулись на него:

Что делать?

Иван стал рисовать на доске:

Бранч это отдельная ветка в коде. Вот смотрите, мы сейчас работаем в trunk-е, основной ветке.

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

Потом Вася закоммитил изменения по улучшению классов появилась версия 1 кода.

Потом он добавил проценты появилась версия кода 2.

При этом в самой VCS сохранены все версии, и мы всегда можем:

  • Посмотреть изменения в версии 1

  • Сравнить файлы из версии 1 и версии 2 система наглядно покажет, где они совпадают, а где отличаются

  • Откатиться на прошлую версию, если версия 2 была ошибкой.

Потом Петя добавил деление появилась версия 3.

И так далее сколько сделаем коммитов, столько версий кода в репозитории и будет лежать. А если мы хотим сделать бранч, то система копирует актуальный код и кладет отдельно. На нашем стволе появляется новая ветка (branch по англ. ветка). А основной ствол обычно зовут trunk-ом.

Теперь, если я захочу закоммитить изменения, они по-прежнему пойдут в основную ветку. Бранч при этом трогать НЕ будут (изменения идут в ту ветку, в которой я сейчас нахожусь. В этом примере мы создали branch, но работать продолжаем с trunk, основной веткой)

Так что мы можем смело коммитить новый код в trunk. А для показа использовать branch, который будет оставаться стабильным даже тогда, когда в основной ветке всё падает из-за кучи ошибок.

С бранчами мы всегда будем иметь работающий код!

Подожди, подожди! А зачем эти сложности? Мы ведь всегда может просто откатиться на нужную версию! Например, на версию 2. И никаких бранчей делать не надо!

Это верно. Но тогда тебе нужно будет всегда помнить, в какой точке у тебя всё работает и тут есть все нужные функции. А если делать говорящие названия бранчей, обратиться к ним намного проще. К тому же иногда надо вносить изменения именно в тот код, который на продакшене (то есть у заказчика).

Вот смотри, допустим, мы выпустили сборку 3, идеально работающую. Спустя неделю Заказчик ее установил, а спустя месяц нашел баг. У нас за эти недели уже 30 новых коммитов есть и куча изменений.

Заказчику нужно исправление ошибки, но он не готов ставить новую версию ведь ее надо тестировать, а цикл тестирования занимает неделю. А баг то нужно исправить здесь и сейчас! Получается, нам надо:

  • Обновиться на версию 3

  • Исправить баг локально (на своей машине, а не в репозитории)

  • Никуда это не коммитить = потерять эти исправления

  • Собрать сборку локально и отдать заказчику

  • Не забыть скопипастить эти исправления в актуальную версию кода 33 и закоммитить (сохранить)

Что-то не очень весело. А если нужно будет снова дорабатывать код? Искать разработчика, у которого на компьютере сохранены изменения? Или скопировать их и выложить на дропбокс? А зачем тогда использовать систему контроля версий?

Именно для этого мы и бранчуемся! Чтобы всегда иметь возможность не просто вернуться к какому-то коду, но и вносить в него изменения. Вот смотрите, когда Заказчик нашел баг, мы исправили его в бранче, а потом смерджили в транк.

Смерджили так называют слияние веток. Это когда мы внесли изменения в branch и хотим продублировать их в основной ветке кода (trunk). Мы ведь объединяем разные версии кода, там наверняка есть конфликты, а разрешение конфликтов это merge, отсюда и название!

Если Заказчик захочет добавить новую кнопочку или как-то еще изменить свою версию кода без проблем. Снова вносим изменения в нужный бранч + в основную ветку.

Веток может быть много. И обычно чем старше продукт, тем больше веток релиз 1, релиз 2... релиз 52...

Есть программы, которые позволяют взглянуть на дерево изменений, отрисовывая все ветки, номера коммитов и их описание. Именно в таком стиле, как показано выше =) В реальности дерево будет выглядеть примерно вот так (картинка из интернета):

А иногда и ещё сложнее!

А как посмотреть, в какой ветке ты находишься?

О, для этого есть специальная команда. Например, в Mercurial это hg sum: она показывает информацию о том, где ты находишься. Вот пример ее вызова:

D:\vcs_project\test>hg sumparent: 3:66a91205d385 tipTry to fix bug with devicebranch: default

В данном примере parent это номер коммита. Мы ведь можем вернуться на любой коммит в коде. Вдруг мы сейчас не на последнем, не на актуальном? Можно проверить. Тут мы находимся на версии 3. После двоеточия идет уникальный номер ревизии, ID кода.

Потом мы видим сообщение, с которым был сделан коммит. В данном случае разработчик написал Try to fix bug with device.

И, наконец, параметр branch! Если там значение default мы находимся в основной ветке. То есть мы сейчас в trunk-е. Если бы были не в нём, тут было бы название бранча. При создании бранча разработчик даёт ему имя. Оно и отображается в этом пункте.

Круто! Давайте тогда делать ветку!

*****

Git создал интерактивную игрушку, чтобы посмотреть на то, как происходит ветвление https://learngitbranching.js.org

*****

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

Итого

Система контроля версий (от англ. Version Control System, VCS) это dropbox для кода.

Популярные VCS и отличия между ними

Наиболее популярные это:

  • SVN простая, но там очень сложно мерджиться

  • Mercurial (он же HG), Git намного больше возможностей (эти системы похожи по функционалу)

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

Mercurial и Git распределенная система контроля версий. Внесение изменений двухступенчатое сначала коммит, потом push. Это удобно, если вы работаете без интернета, или делаете мелкие коммиты, но не хотите ломать основной код пока не доделаете большую задачу. Тут есть и автоматическое слияние разных бранчей. Больше возможностей дают системы.

У любой системы контроля версий есть консольный интерфейс. То есть общаться с ними можно напрямую через консоль, вводя туда команды. Склонировать репозиторий, обновить его, добавить новый файл, удалить старый, смерджить изменения, создать бранч... Всё это делается с помощью команд.

Но есть и графический интерфейс. Устанавливаете отдельную программу и выполняете действия мышкой. Обычно это делается через черепашку программа называется Tortoise<VCS>. TortoiseSVN, TortoiseHG, TortoiseGit... Часть команд можно сделать через среду разработки IDEA, Eclipse, etc.

Но любой графический интерфейс как работает? Вы потыкали мышкой, а система Tortoise составила консольную команду из вашего тык-тык, её и применила.

См также:

Что такое API подробнее о том, что скрывается за интерфейсом.

Вот некоторые базовые команды и форма их записи в разных VCS:

Действие

SVN

GIT

HG

Клонировать репозиторий

svn checkout <откуда> <куда>

git clone <откуда> <куда>

hg clone<откуда> <куда>

Обновить локальную сборку из репозитория

svn update

git pull

hg pull -u

Проверить текущую версию (где я есть?)

svn log --revision HEAD

git show -s

hg sum

Закоммитить изменения

svn commit -m "MESSAGE"

git commit-a-m "MESSAGE"


git push

hg commit -m "MESSAGE"


hg push

Переключиться на branch

svn checkout <откуда> <куда>

git checkout BRANCH

hg update BRANCH

Тут хочу напомнить, что я тестировщик, а не разработчик. Поэтому про тонкости различия коммитов писать не буду, да и статья для новичков, оно им и не надо =)

Пример выкачиваем проект из Git

Выкачивать мы будем систему с открытым исходным кодом Folks. Так что вы можете повторить этот пример сами!

Для начала установите Git. Когда он установлен, можно выкачивать репозиторий на свой компьютер. Я покажу 3 способа (есть и другие, но я покажу именно эти):

  1. Через консоль

  2. Через IDEA

  3. Через TortoiseGit

Исходный код мы будем в директорию D:\git.

1. Через консоль

1. Запустить консоль git:

2. Написать команду:

git clone Откуда Куда
git clone https://bitbucket.org/testbasecode/folks/src/master/ D:\\git\\folks_console

В консоли нужно писать простой слеш или экранировать обратный. Иначе консоль его проигнорирует!

Также НЕ НАДО использовать в названии папки куда клонируем русские символы или пробелы. Иначе потом огребете проблем на сборке проекта.

2. Через IDEA

1. Запустить IDEA

2. Check out from Version Control Git

3. Заполнить поля:

  • URL https://bitbucket.org/testbasecode/folks/src/master/ (откуда выкачиваем исходный код)

  • Назначение D:\git\folks_idea (куда сохраняем на нашем компьютере)

4. Нажать Clone всё! Дальше IDEA всё сделает сама!

А под конец предложит открыть проект, подтверждаем!

Если открывается пустой серый экран, найдите закладку Project (у меня она слева сверху) и щелкните по ней, чтобы раскрыть проект:

И вуаля и код скачали, и сразу в удобном и бесплатном редакторе открыли! То, что надо. Для новичка так вообще милое дело.

3. Через TortoiseGit

Еще один простой и наглядный способ для новичка через графический интерфейс, то есть черепашку (tortoise):

1. Скачать TortoiseGit

2. Установить его Теперь, если вы будете щелкать правой кнопкой мыши в папочках, у вас появятся новые пункты меню: Git Clone, Git Create repository here, TortoiseGit

3. Перейти в папку, где у нас будет храниться проект. Допустим, это будет D:\git.

4. Нажать правой кнопкой мыши Git Clone

Заполнить поля:

  • URL https://bitbucket.org/testbasecode/folks/src/master/ (откуда выкачиваем исходный код)

  • Directory D:\git\folks_tortoise_git (куда сохраняем на нашем компьютере)

5. Нажать Ок

Вот и всё! Система что-то там повыкачивает и покажет результат папочку с кодом!

Итого мы получили 3 папки с одинаковым кодом! Неважно, какой способ выберете вы, результат не изменится:

Итого

Пусть вас не пугают страшные слова типа SVN, Mercurail, Git, VCS это всё примерно одно и то же. Место для хранения кода, со всеми его версиями. Дропбокс разработчика! И даже круче =) Ведь в дропбоксе любое параллельное изменение порождает конфликтную версию.

Я храню свою книгу в дропбоксе. Там же лежит файл для художницы TODO Вике. Когда я придумываю новую картинку, тодобавляю ее в конец файла. Когда Вика заканчивает рисовать, она отмечает в ТЗ, какая картинка готова.

Мы правим разные места. Вика идет сначала, я добавляю в конец. Казалось бы, можно сохранить и ее, и мои изменения. Но нет, если файл открыт у обеих, то при втором сохранении создается конфликтная копия. И надо вручную синхронизировать изменения.

Гуглодок в этом плане получше будет, его можно редактировать параллельно. И если менять разные места, конфликтов совсем не будет!

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

Когда вы приходите на новую работу, вам нужно выкачать код из хранилища. Это означает просто забрать из общего хранилища актуальную версию. Как если бы вы зашли в дропбокс и скопипастили себе последнюю версию файлов. Просто в VCS это делается при помощи командной строки или специального графического интерфейса типа Tortoise Hg.

Это нестрашно =) Посмотрите выше пример буквально 1 команда позволяет нам получить этот самый код.

А потом уже, если разрешат, вы сможете даже вносить свои изменения в основной код или код автотестов. Но если уж вы с этим справитесь, то с коммитом и подавно!

PS: больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале.

PPS: автор картинок этой статьи Аня Черноморцева, автор стиля Виктория Лапис =)

Подробнее..

Перевод Актуальные инструменты контроля версий данных в 2020 году

12.11.2020 18:15:59 | Автор: admin
Все мы знаем и любим Git. И, конечно же, были придуманы его аналоги для управления версиями данных, чтобы эксперименты с данными были воспроизводимыми, а действия команд согласованными. Сегодня, в преддверии старта нового потока курса по Data Science, делимся с вами материалом о сравнении нескольких систем контроля версий. Подробности сравнения как обычно, под катом.



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

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

Проблемы управления данными


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

Пространство хранилища


Обучающие данные могут занимать значительное место в репозиториях git. Это связано с тем, что git разработан для отслеживания изменений в текстовых, но в небольших бинарных файлах. Поэтому, когда наборы тренировочных данных содержат большие аудио- или видео-файлы, в дальнейшем это приносит много проблем. Каждое изменение в наборе обучающих данных приводит к дублированию набора данных в истории репозиториев. Такое дублирование не только делает репозиторий большим, но и значительно замедляет его клонирование и перебазирование (git rebase).

Управление версиями данных


В попытке управлять версиями (будь то код или пользовательский интерфейс) даже среди технарей широко распространена тенденция управлять версиями, добавляя номер версии или слово в конец имени файла.

В контексте данных это означает, что проект может содержать файлы data.csv, data_v1.csv, data_v2.csv, data_v3_finalversion.csv и т.д. Эта плохая привычка не просто клише: с плохих привычек версионирования на самом деле начинают большинство разработчиков, дата-сайентистов и экспертов пользовательского интерфейса.

Photo by Steve Johnson/Unsplash

Многопользовательская среда


При работе в производственной среде одна из самых больших проблем работа с другими дата-сайентистами. Если вы не используете какую-то форму управления версиями в среде совместной работы, файлы удаляются, изменяются и перемещаются, а вы не знаете, кто и что сделал. Кроме того, сложно вернуть данные в исходное состояние. Когда речь заходит об управлении моделями и наборами данных, это одна из самых больших проблем.

Обзор лучших альтернатив в управлении версиями данных


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

DVC


DVC, или Data Version Control, это один из многих доступных инструментов с открытым исходным кодом, упрощающих работу с проектами Data Science и ML.

Используется подход Git'а в том смысле, что дает интерфейс командной строки, который настраивается в несколько простых шагов. DVC, как предполагает его название, фокусируется не только на версионировании данных. Инструмент помогает командам управлять конвейерами и моделями машинного обучения. В конце концов, DVC способствует согласованности вашей команды и воспроизводимости ваших моделей.

Преимущества


  • Лёгкий, исходники открыты, подходит для всех основных облачных платформ и типов хранилищ данных.
  • Гибкий, независимый от формата и фреймворка, лёгкий в применении.

Недостатки


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



Delta Lake


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

Преимущества


  • Предлагает множество функций, которые могут не входить в вашу систему хранения данных, например ACID-транзакции или эффективное управление метаданными.
  • Снижает необходимость в ручном управлении версиями данных и ручном решении других связанных с данными вопросов, позволяя разработчикам сосредоточиться на построении продуктов поверх озёр данных.

Недостатки


  • Delta Lake часто бывает перегибом для большинства проектов: инструмент был разработан для работы со Spark на больших данных.
  • Требуется специальный формат данных, а это означает, что инструмент теряет в гибкости и зависим в отношении текущих форматов.
  • Основная задача инструмента действовать в качестве скорее уровня абстракции данных, а это может быть не тем, что нужно вашей команде, и также может игнорировать разработчиков, которым нужно решение легче.



Git LFS


Git LFS разработанное рядом разработчиков расширение Git'а с открытым исходным кодом. Это ПО предназначено для устранения больших файлов, которые могут быть добавлены в ваше хранилище (например фотографий и наборов данных) с помощью указателей. Указатели легче, они указывают на хранилище LFS. Таким образом, когда вы отправляете изменения из вашего репозитория в основной, обновление не занимает много времени или места. Это очень легковесный вариант для управления данными.

Преимущества


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

Недостатки


  • Git LFS для хранения ваших данных требует выделенных серверов. Это, в свою очередь, в конечном счёте приводит к тому, что ваши группы дата-сайентистов оказываются заблокированными, а также к увеличению объема инженерной работы.
  • Серверы Git LFS не предназначены для масштабирования в отличие от DVC, который хранит данные в более общем и легко масштабируемом хранилище объектов, например S3.
    Очень специфичен и может потребовать использования ряда других инструментов для иных этапов рабочего процесса в Data Science.



Pachyderm


Pachyderm одна из немногих платформ для сбора данных в этом списке. Цель Pachyderm создать платформу, позволяющую легко воспроизводить результаты моделей ML, управляя всем рабочим процессом обработки данных. В этом отношении Pachyderm Docker для данных.

Pachyderm использует контейнеры Docker для упаковки вашей среды выполнения. Это позволяет легко воспроизвести результат. Сочетание версионирования данных и Docker дает специалистам Data Science и командам DevOps легко развёртывать модели и обеспечивать их согласованность. Компания Pachyderm взяла на себя обязательства по Биллю о правах в Data Science, в котором изложены основные цели продукта: воспроизводимость, знание истории данных, сотрудничество, инкрементальность и автономия, а также абстрагирование инфраструктуры. Эти принципы определяют многие из особенностей продукта и позволяют командам воспользоваться преимуществ инструмента в полной мере.

Преимущества


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

Недостатки


  • Кривая обучения круче из-за большого количества подвижных частей, таких как сервер Kubernetes, необходимый для управления бесплатной версией Pachyderm.
  • При наличии различных технических компонентов сложно будет интегрировать Pachyderm в уже существующую инфраструктуру.



Dolt


Dolt уникальное решение для версионирования данных. В отличие от некоторых других представленных вариантов, которые просто содержат данные о версии, Dolt это база данных SQL с версиями в стиле Git. Но в отличие от Git'а, где в центре файлы, у Dolt в центре таблицы. Это означает, что вы можете обновлять и изменять данные, не беспокоясь о потере изменений. Приложение ещё новое, в ближайшем будущем планируется сделать его на 100 % совместимым с Git и MySQL.

Преимущества


  • Инструмент лёгкий, и его код частично открыт.
  • SQL-интерфейс делает его доступнее для аналитиков данных в сравнении с более непонятными вариантами.

Недостатки


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



LakeFS


LakeFS позволяет командам строить повторяющиеся, атомарные и версионированные операции с данными об озёрах. На сцене Dolt новичок, но он наносит удар. Предоставляется Git-подобная модель ветвления и управления версиями, предназначенная для работы с вашим озером данных, и она масштабируется до петабайт данных.

Подобно Delta Lake, LakeFS обеспечивает соответствие ACID в ваших озёрах данных. Однако LakeFS поддерживает как AWS S3, так и Google Cloud Storage в качестве бэкендов, а это означает, что для использования всех преимуществ не требуется использовать Spark.

Преимущества


  • Предоставляет расширенные возможности, такие как ACID транзакции, для лёгкости использования облачного хранения данных (например S3 и GCS), и всё это вне зависимости от формата.
  • Легко масштабируется, поддерживая очень большие озёра данных. Способен предоставить контроль версий как для среды разработки, так и для производственной среды.

Недостатки


  • LakeFS относительно новый продукт, поэтому по сравнению с другими решениями функции и документация могут меняться быстрее.
  • Ориентирован на версионирование данных, а это означает, что вам потребуется использовать ряд иных инструментов для других этапов рабочего процесса Data Science.



Вам Действительно нужно управление версиями данных?


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



К некоторым данным, таким как веб-трафик, другие данные только добавляются. Это означает, что данные добавляются, но редко изменяются. То есть версии данных, необходимых для создания воспроизводимых результатов, это даты начала и окончания. Важно это отметить, поскольку в таких случаях, возможно, вам удастся избежать установки упомянутых выше инструментов. Вам всё равно нужно будет управлять датами начала и окончания, чтобы убедиться, что вы тестируете систему и модели на одних и тех же данных. Однако в таких случаях не обязательно фиксировать все данные в системе версионирования.

Итоги


Управление версиями данных необходимый шаг для команд дата-сайентистов, позволяющий избежать несоответствий выходных данных. Используете ли вы Git-LFS, DVC или другой обсуждаемый инструмент, потребуется некоторая версионность данных. Эти инструменты версионирования данных могут помочь сократить объем памяти, необходимый для управления наборами данных, а также помочь отслеживать вносимые членами команды изменения. Без инструментов для версионирования данных ваш дежурный специалист может отлаживать модель в 3 часа ночи из-за проблемы, возникшей по причине несовпадения результатов моделирования. Однако всего этого можно избежать, если ваши команды специалистов по работе с данными внедрили процесс управления версиями данных.

На тот случай если вы задумали сменить сферу или повысить свою квалификацию промокод HABR даст вам дополнительные 10% к скидке указанной на баннере.

image



Рекомендуемые статьи


Подробнее..

Вначале былworkflow

08.12.2020 14:22:23 | Автор: admin

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

Часть 1: Рабочий процесс

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

А далее как обычно бывает: всплывают первые запросы от пользователей на добавление новых фич/устранение багов ит.д., разработка кипит. Для того чтобы ускорить выход новых версий, принимается решение расширить командуDevOpsом, и для решения насущных проблемDevOpsпредлагает построитьCI/CD-конвейер (pipeline). И вот пришло время рассмотреть, как жеCI/CD-конвейерляжет на нашрабочий процесс,где у нас сейчас только мастер.

Для примера мы взяли простойконвейерс одним окружением. И вроде всёвыглядит хорошо: разработчик запушил код в мастер, запустилсяконвейер, код прошёл ряд проверок, собрался и развернулся в окружении.

А теперь рассмотрим ситуацию, когдаконвейерпрервался на тестах.

То есть тесты показали, что в текущей версии мастера есть ошибки. Нам на руку, что в нашем примереконвейерпрервался, и на окружении до сих пор работающее приложение, и пользователь остаётся довольным. А вот что начинается в команде разработки:

На данной картинке (которая может показаться слишком преувеличенным примером, однако такое бывает), мы видим,что в первом коммите, который ранее попал на окружение,каких-либо проблем нет.На втором коммите в мастерконвейерпрервался.И вот тут начинается самое интересное. Понятно, что запушенный код нерабочий и надо его исправлять, чем и занялся разработчик. Но что,еслиу нас не один разработчик, а команда, где каждый усердно трудится над своей задачей? Второй разработчик ответственно начал добавлять новые улучшения в продукт, но в их основе лежит второй коммит. Что же будет дальше с этими изменениями? Сколько времени уйдёт у первого разработчика на исправление? Насколько сильными будут изменения в новом коммите? Что в это время делать второму разработчику? Что делать с уже написанными вторым разработчикомфичами? В общем, слишком много вопросов, а на выходе получаем:

  • уменьшение производительности,

  • впустую потраченное время,

  • много головной боли.

Для решения насущных проблемможноприбегнуть к изменениюрабочего процесса.

Первым делом добавимнебезызвестныеfeature-ветки.

В отдельныхfeature-ветках каждый разработчик может без стресса заниматься своей задачей. При этом мы блокируем коммиты напрямую в мастер (или договариваемся так не делать),и впоследствии все новые фичи добавляютсяв мастерчерез mergerequest.

И в очередной разпроиграемпроблему: вfeature-ветке обнаружен баг.

При такомрабочем процессе, если находится какая-либо неполадка,разработчик спокойно занимается исправлением, не влияя на работу остальной команды,и в мастере находится рабочий код, а следовательно, и окружение остаётся рабочим.

Но что,еслина окружение попал новый мастер,и спустя какое-то время обнаружен баг (не углядели, всякое бывает).

Соответственно, это уже критическая ситуация: клиент не доволен, бизнес не доволен. Нужно срочно исправлять! Логичным решением будет откатиться. Но куда? Заэтовремя мастер продолжал пополняться новыми коммитами. Даже если быстро найти коммит,в котором допущена ошибка,и откатить состояние мастера, то что делать с новыми фичами, которые попали в мастер после злосчастного коммита? Опять появляется много вопросов.

Что ж, давайте не будем поддаваться панике,и попробуем ещёраз изменить нашрабочий процесс,добавив теги.

Теперь,когда мастерпополняетсяизменениями изfeature-веток, мы будем помечать определённое состояниемастера тегом.

Но вот в очередной раз пропущен баг в тегеv2.0.0, который уже на окружении.

Как решить проблему теперь?

Правильно, мы можем повторно развернуть версиюv1.0.0, считая её заведомо рабочей.

И таким образом, наше окружение снова рабочее. А мы,в свою очередь,ничего не делая,получилиследующее:

  • сэкономили время и,как следствие,деньги,

  • восстановили работоспособность окружения,

  • предотвратили хаос,

  • локализовали проблему в версииv2.0.0.

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

Для примера возьмём и рассмотримдавновсем известныйGitFlow:

Сравним его с нашим последним примером иувидим,что у нас нетdevelop-ветки, а ещёмы не использовалиhotfixes-ветки. Следовательно,мы не можем сказать, что использовали именноGitFlow. Однако мы немного изменим наш пример, добавивdevelop-иrelease-ветки.

И теперьвкаком-топриближениинаш пример стал похожим наGitFlow.Однакочто мы получили в этом случае? Какие проблемы нам удалось решить и как нам удалось улучшить нашу жизнь? По моему мнению,добив нашрабочий процессдоGitFlow, который многие используюткакэталонную модель,мы всего-навсего усложнили себе жизнь. И здесь я не хочу сказать, чтоGitFlowплохой, просто в наших простых примерах он определённо излишний.

Что ж, наGitFlowжизнь не заканчивается, ведь есть не менее известныйGitHubFlow.

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

Собственно, сравнив нашрабочий процессиз примера сGitFlowиGitHubFlow,хотелось бы подчеркнуть следующее: безусловно,существование паттернов для построения рабочих процессовэто огромный плюс, так как мы можем взять существующий паттерн и начать работать по нему,и в определённых случаях какой-либо определённый паттерн идеально впишется в процесс разработки. Однако это работаетив другую сторону:какой-либо существующий паттернможетвставитьнам палки в колесаи усложнить процесс разработки.

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

Часть 2: Участь DevOps'а

В первой части мы рассмотрели, как выглядитрабочий процесс, а теперь посмотрим, почему для DevOps-инженератак важен корректно настроенный рабочий процесс.Для этого вернёмся к последнему примеру,аименно к построению того самогоконвейерадля реализации процесса CI/CD.

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

Собственно, построениеконвейераможно изобразить вот такой простой картинкой:

Ну или одним вопросом: как связать между собой код в репозитории и окружение?

Следовательно, нужно понимать,какой именно код должен попасть в окружение, а какой нет. К примеру, еслив ответна вопрос: Какойрабочий процессиспользуется? мы услышим: GitHubFlow, то автоматически мы будем искать нужный код вmaster-ветке. И ровно наоборот, если не построен никакойрабочий процесси куски рабочего кода разбросаны по всему репозиторию, то сначала нужно разобраться срабочим процессом, а лишь потом начинать строитьконвейер.Иначе рано или поздно на окружение попадёт то, что возможно не должно там быть, и как следствие,пользователь останется без сервиса/услуги.

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

Нодля наглядностидалее рассмотрим два основных этапа вCI/CD- конвейерах: build и deployment/delivery. И начнем мы,пожалуй,с первогоbuild.

Buildпроцесс, конечным результатом которого является артефакт.

Дляпростотывведём следующее условие:артефакты должныверсионироватьсяи храниться в каком-либо хранилище для последующего извлечения. Что ж, если у нас нетрабочего процесса, то первый (возможно,глупый,но важный)вопроскак мы будем именовать артефакты при хранении. Опять же, вернёмся к нашему примеру срабочим процессом, где мы использовали теги.

Так вот, у нас есть отличная возможность взять имя тега для артефакта и опубликовать его. Но что,если у нас нет никакогорабочего процесса?Что ж, тут уже сложнее. Конечно, мы можем взятьхешкоммита,или дату, или придумать что-либо ещёдля идентификации артефакта.Но очень скороразобраться в этом будет практически невозможно.

И вот пример из реальной жизни.

Представьте ситуацию, когда вы хотите загрузить новую версиюUbuntu, и вместо такого списка версий:

...увас будет списокхешейкоммитов. Следовательно, это может бытьнеудобноне только для команды, но и для пользователя.

Бываютслучаи, когда мы можем пренебречь именованием. Поэтому рассмотрим ещёодин небольшой пример:у нас нет конкретногорабочего процесса;как следствие,у нас нет понимания,что именно мы должны хранить в нашем хранилище. Что,в свою очередь,может бытьчреватопоследствиями, так как хранилище так или иначе ограничено: либо деньгами, либо местом, либо и тем,и другим. Поэтому в ситуации, когда у нас нет конкретногорабочего процесса,мы можем начать публиковать артефакт из каждойfeature-ветки (так как чёткой определённости у нас нет), но в таком случае рано или поздно возникнет ситуация, когда ресурсы закончатся, и придётся расширяться, что опять же несёт за собой трату как человеческих, так и денежных ресурсов.

Конечно,на этом примеры не заканчиваются, но думаю,чтотеперь мы можем перейти к delivery/deployment.

Deliveryпроцесс,в рамках которого развёртка приложения на окружении происходит вручную.

Deploymentпроцесс,в рамках которого развёртка приложения происходит автоматически.

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

Если же говорить оdeployment, абсолютно неправильно реализовыватьcontinuousdeploymentв случае, когда у нас не выстроенрабочий процесс.Потому чтонесложнопредставить, что будет,если изменения в коде каждый раз будут автоматически попадать на окружение.

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

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

Заключение

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru