В последнем релизе уходящего года мы завершаем наш Мастер-план и хотим показать вам кое-что интересное из того, над чем мы работали.
В GitLab 8.15 появилась фича Auto Deploy – автоматизированная настройка развертывания и приложений для ревью (Review Apps). Для проекта на Ruby on Rails такая настройка займёт меньше минуты. Посмотрите, как это работает, в видео на 1:42.
Вдобавок, доступ к вашим средам (environments) стал быстрее и проще: через терминал непосредственно в GitLab (там же на 5:18)
Мы хотим дать каждому возможность использовать всю мощь контейнеров (containers), непрерывной интеграции и развертывания (continuous integration and deployment, сокращенно CD/CI), приложений для ревью (review apps) и планировщиков контейнеров (container schedulers). В GitLab 8.15 мы взяли на себя всю сложную работу по настройке, и вся она происходит совершенно прозрачно. В демонстрационном видео мы настраиваем и разворачиваем Ruby-приложение с review apps, несколькими средами и чатопсом (chatops, управление инфраструктурой через интеграцию с чатом) на кластер Kubernetes примерно за 12 минут. Без GitLab такая задача обычно занимает дни, если не недели.
Для большинства из нас декабрь — месяц праздников и подарков. GitLab тоже получил в подарок много новых фич.
MVP месяца — Michael Munch, который интегрировал в GitLab красивое отображение математических формул (LaTeX). Michael работал над этой функциональностью больше полугода в нескольких мерж-реквестах (merge requests) с более чем тремя сотнями комментариев.
Мы также хотим поблагодарить Warren Postma за его помощь в нашем трекере задач и на форуме сообщества и в целом за популяризацию GitLab.
Ещё одна благодарность — Elan Ruusamäe и Dirk Hörner за их вклад в технический дизайн и реализацию фич, которые значительно усилили git-хуки (git hooks) в GitLab.
Спасибо вам, Warren, Michael, Elan, и Dirk!
Мы хотим, чтобы настройка полнофункционального конвейера CI/CI (CI/CD pipeline) с развертыванием через планировщик контейнеров (container scheduler) была доступна каждому. Она должна быть легкой в освоении, но при этом масштабируемой и прозрачной.
Auto Deploy дает возможность такой настройки. В вашем проекте появится новая кнопка, по нажатию на которую будет создан мерж-реквест (merge request, он же pull request) с шаблоном файла .gitlab-ci.yml
, содержащим сценарий развертывания в используемый вами планировщик контейнеров с помощью Docker. Также в этом шаблоне присутствует настройка Review Apps, поэтому на работу новой фичи можно будет посмотреть сразу — еще до того, как вы примете мерж-реквест.
Это, пожалуй, самый быстрый путь к развертыванию в одно нажатие кнопки, в котором реализация прозрачна, все настройки хранятся в git, и со всем этим легко работать в команде.
Настройка Auto Deploy в GitLab 8.15 показывается в видео на 1:42.
Это первая итерация, и пока что доступен только шаблон для развертывания на внешний (external) кластер OpenShift. Мы используем Herokuish и Heroku Buildpacks, чтобы упаковать ваше приложение в докер-образ (docker image) и развернуть его в Kubernetes на OpenShift. В будущем мы планируем добавить поддержку других планировщиков контейнеров и облачных платформ (таких как обычный кластер Kubernetes, Mesos и Docker Swarm). Мы будем рады вашему вкладу в коллекцию шаблонов.
За подробной информацией обращайтесь к документации по Auto deploy.
Представьте себе ситуацию: в вашем GitLab настроены и работают несколько динамических сред, созданных по запросу из того или иного проекта. Это могут быть приложения для ревью, staging или production-среды. Обычно для получения прямого доступа к ним нужно прикладывать лишние усилия. Это досадное ограничение: бывает полезно сделать что-то своими руками ради эксперимента или для отладки.
С веб-терминалом (web-terminal) эта задача сильно упрощается. Достаточно зайти на страницу сред вашего проекта и нажать на кнопку терминала. GitLab сам установит SSH-соединение с нужным хостом и предоставит вам полноценную консоль в окне браузера.
В демонстрационном видео работа веб-терминала показана на 5:18. Мы с нетерпением ждем отзывов о том, как эта фича помогла вам ускорить работу.
Подробная информация о настройке и использовании веб-терминала находится в документации для системных администраторов и в пользовательской документации по рабочим средам (environments).
Импорт из Bitbucket стал еще более гибким. В GitLab 8.15 мы добавили импорт пулл-реквестов вместе с комментариями в мерж-реквесты GitLab, а также импорт milestone’ов (метки больших этапов разработки, которыми отмечаются обычные задачи) и вики-страниц. Итого, получается следующий список импортируемых объектов:
При импорте сохраняются все ссылки на пулл-реквесты и задачи, а также уровни доступа (публичный или приватный)
Подробнее об импорте из Bitbucket – в документации
GitLab предоставляет возможность использования git-хуков для применения определенных правил и триггеров для пушей и их содержимого. Однако, до сих пор единственной возможностью стандартизации этих правил между проектами было их копирование в каждый новый проект.
С добавлением глобальных хуков стало возможным создавать git-хуки, которые будут применяться для каждого проекта в инстансе GitLab. Это должно упростить применение единых правил для всего нового кода.
Создавайте хуки в директории hooks/<hook_name>.d/
или укажите GitLab Shell путь до директорий с ними.
Документация по кастомным хукам
При создании кастомных git-хуков может иметь значение порядок их применения: если определенный хук не выполняется, нет никакого смысла пытаться выполнить последующие. Упорядоченные хуки выполняются в лексическом порядке и прекращают выполнение при неудаче любого из них.
К примеру, при создании хуков 1-hook.sh
и 2-hook.sh
, 1
всегда будет выполняться перед 2
.
Данное нововведение усиливает функциональность хуков и добавляет возможности для кастомизации обработки входящих коммитов.
Больше информации на эту тему содержится в документации по git-хукам.
Спасибо Elan Ruusamäe и Dirk Hörner за помощь в разработке и имплементации данной функциональности, а также глобальных git-хуков!
В GitLab EE существует возможность синхронизации LDAP групп с группами GitLab, таким образом назначая всем пользователям группы определенный уровень доступа. К примеру, можно назначить всем пользователям в LDAP группе developers
уровень доступа Developer
. Таким образом, при добавлении новых разработчиков в LDAP группу, им будет автоматически выдаваться соответствующий уровень доступа.
GitLab 8.15 расширяет возможности этой функциональности. Теперь, вдобавок к автоматической синхронизации уровней доступа, появилась возможность его переопределения для конкретного пользователя. Данное нововведение упрощает управление уровнями доступа между группами и проектами.
В версии 8.14 мы добавили Chatops в GitLab через интеграцию с Mattermost, а теперь делаем то же самое для Slack! То есть теперь вы сможете создавать, показывать и искать задачи прямо из Slack, что позволяет с легкостью переходить от обсуждения задачи к оформлению ее в трекере.
К тому же, теперь можно проводить развертывание в/из любой среды. Например, при вводе
/awesome-website deploy from staging to production
GitLab проведет развертывание последнего коммита из staging в master.
Chatops для Slack можно настроить в свойствах проекта. Как всегда, мы рады вкладу пользователей в развитие интеграции чатов с GitLab.
Сильно упрощена интеграция GitLab с Mattermost. Теперь это делается одним кликом, как показано в этом видео на 3:16.
Интеграция с Mattermost и Slack позволяет создавать, показывать и искать задачи, а также производить развертывание в любую среду.
Как вам известно, когда кто-то комментирует ваш дифф, вам отправляется письмо с нотификацией. Теперь в такие письма добавляется часть этого диффа, чтобы у вас сразу был контекст перед глазами.
Мы с вами приложили серьезные усилия для упрощения работы пользователей с GitLab. Как следствие, в данном релизе содержится множество изменений, делающих работу с GitLab еще более приятной.
С целью улучшения читабельности и поддержки различных ОС/браузеров GitLab теперь использует системные шрифты. Эти шрифты оптимизированы под определенные платформы, благодаря чему работать с GitLab одинаково комфортно, независимо от того, откуда вы это делаете.
Для наглядности можно ознакомиться с оригинальным мерж-реквестом.
Для улучшения читабельности уменьшена максимальная ширина контейнера задач и мерж-реквестов. Это только первый шаг в процессе уменьшения огромной длины строк, которую можно наблюдать во всем GitLab’е. За ходом работы над этой задачей можно наблюдать в соответствующем тикете.
Изменен внешний вид меток, теперь они сильнее визуально отличаются от кнопок. Мы продолжаем работу в этом направлении с целью сделать метки и значки статуса еще более различимыми и узнаваемыми в будущих версиях.
Прокрутка и загрузка сборок теперь лучше работает и выглядит:
Сделав системные шрифты и улучшив автодополнения, мы существенно уменьшили размер всех страниц в GitLab. Данный мерж-реквест в проекте GitLab CE вместо 1800 Кбайт теперь занимает 718 Кбайт!
Чтобы помочь новым пользователям освоить GitLab, мы добавили информативные и забавные подсказки для множества пустых страниц по всему приложению. Загляните в наш мета тикет, чтобы узнать, где мы разместили новые подсказки, и не стесняйтесь предлагать свои!
В комментариях и файлах репозитория теперь можно аккуратно оформлять математические данные, используя библиотеку KaTeX от Khan Academy.
Чтобы оформить внутристрочные математические формулы, используйте знаки доллара вокруг кода строки: $`a^2+b^2=c^2`$
Чтобы оформить многострочные математические выражения, используйте язык math
для блока кода:
```math
a^2+b^2=c^2
```
Это работает не только с Markdown, но и с документами AsciiDoc. Прочитать документацию о поддержке математики
За эту фичу спасибо Michael Munch.
В предыдущих версиях сообщения коммитов мержей состояли из заголовка, описания мерж-реквеста и ссылки на мерж-реквест. Это тяжело читать при использовании git log
и аналогичных функций, так как описания мерж-реквестов часто содержат запросы на ревью, скриншоты и другие детали, несущественные для изменения кода.
Теперь сообщение коммита мержа по умолчанию выглядит так:
Merge branch '$SOURCE_BRANCH' into '$TARGET_BRANCH'
$TITLE
Closes $CLOSING_ISSUE_REFERENCES # only present if the MR closes issues
See merge request $MERGE_REQUEST_REFERENCE
Предыдущее дефолтное сообщение доступно в настройках сообщения коммита мержа.
Спасибо Gabriel Gizotti!
Раньше ссылки на что-либо в другом проекте всегда включали пространство имен, даже если проект был в том же пространстве имен.
Теперь доступны краткие ссылки. Внутри проекта
gitlab-org/gitlab-ce
вы теперь сможете обратиться к задаче под номером 1 в GitLab Workhorse,
написав gitlab-workhorse#1
вместо gitlab-org/gitlab-workhorse#1
,
сэкономив драгоценное время на нажатиях клавиш!
Больше информации в специальной секции о ссылках GitLab в нашей документации о Markdown.
Спасибо Oswaldo Ferreira!
В версии 8.14 мы добавили возможность блокировать мерж, когда имеются нерешенные обсуждения.
Теперь мы добавили возможность создавать новый тикет из нерешенного обсуждения в мерж-реквесте, и одновременно разрешать это обсуждение. Это полезно в случаях, когда вам нужно мержить что-то новое, но не хочется забыть о комментариях из ревью кода.
Спасибо Bob van Landuyt!
Ручные действия позволяют вам запрашивать ручное взаимодействие до перехода на конкретную задачу в CI. Весь ваш конвейер может работать автоматически, но непосредственно для развертывания в production нужно сделать клик.
Сделать это можно прямо из схемы конвейера. Нужно только кликнуть на кнопку «Play», чтобы запустить конкретную задачу.
Чтобы вы могли быстро понять, когда пользователь в последний раз использовал GitLab, мы добавили к GitLab специальное администраторское API. Оно позволяет получать timestamp последней активности любого пользователя в инстансе.
Теперь вам будет проще находить людей в проектах и группах с помощью сортировки по имени, уровню доступа или дате присоединения.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: https://about.gitlab.com/2016/12/22/gitlab-8-15-released/
Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru. Над переводом работали @nick_volynkin, @rishavant и @sgnl_05.