GitLab 12.10 помогает командам контролировать и улучшать соответствие требованиям с новой фичей «управление требованиями», уменьшать время цикла и ускорять поставку программного обеспечения благодаря CI с автоматическим масштабированием на AWS Fargate и более эффективно управлять портфелем проектов с отображением состояния тикетов и эпиков (в русской локализации GitLab «цели»).
Мы открываем исходный код фич со стадий Plan, Create, Verify, Package, Release, Configure и Defend.
На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).
Ее основными тезисами были:
Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.
Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.
Новый релиз GitLab 12.8 посвящен подходу «единое место»: для всех ваших логов, пакетов NuGet и контроля за соответствием требованиям. По аналогии с тем, что GitLab — это единое место для всего вашего жизненного цикла DevOps.
Никогда не было, и вот опять!
На очередном проекте мы решили использовать Liquibase с самого начала, чтобы избежать проблем в будущем. Как оказалось, не все молодые члены команды умеют его правильно использовать. Я провёл внутренний воркшоп, который затем решил превратить в статью.
Статья включает в себя полезные советы и описание трех самых явных ловушек, в которые можно попасть, работая с инструментами миграции реляционных баз данных, в частности Liquibase. Рассчитана на Java разработчиков уровня Junior и Middle, для более опытных разработчиков может быть интересна для структуризации и повторения того, что, скорее всего, уже известно.
Недавно случайно узнал, что BitBucket, где лежат мои Mercurial-репозитории, прекращает поддержку Mercurial: новые репозитории создавать уже нельзя, а существующие будут удалелы с 1.06.2020. Возможные варианты действий: перейти на Git, выбрать один из других сервисов, или настроить хостинг Mercurial на своём сервере. Сервер у меня есть, отказываться от Mercurial и менять привычки как-то не хочется, альтернативы BitBucket мне тоже не приглянулись — поэтому выбрал последний вариант. Задача вроде несложная, вот только сервер у меня под Windows, и, кажется, в процессе настройки я умудрился наступить на максимум возможных граблей. Надеюсь, эта статья поможет кому-нибудь избежать этого и сэкономить время.
Вышел релиз GitLab 12.7 — с улучшениями, которые помогут вашим командам и конвейерам (в русской локализации GitLab «сборочные линии») стать более эффективными и результативными. Настройка автоматизации и конвейеров — основа продуктивной работы команд DevOps, и в 12.7 мы предлагаем множество нововведений, которые сделают вашу работу быстрее и эффективнее. Например, конвейеры Parent-Child, группы ресурсов конвейера и бета-версию общих обработчиков заданий (shared runner) для Windows на GitLab.com.
Руководителям разработки необходим четкий и понятный обзор состояния безопасности приложения и соответствия требованиям для их проектов. Декабрьский релиз GitLab поможет вам эффективнее отслеживать эти важные параметры.
Привет! За последнее время вышло много классных инструментов автоматизации как для сборки Docker-образов так и для деплоя в Kubernetes. В связи с этим решил поиграться с гитлабом, как следует изучить его возможности и, конечно же, настроить пайплайн.
Вдохновлением для этой работы стал сайт kubernetes.io, который генерируется из исходных кодов автоматически, а на каждый присланный пул реквест робот автоматически генерирует preview-версию сайта с вашими изменениеми и предоставляет ссылку для просмотра.
Я постарался выстроить подобный процесс с нуля, но целиком построенный на Gitlab CI и свободных инструментах, которые я привык использовать для деплоя приложений в Kubernetes. Сегодня я, наконец, расскажу вам о них подробнее.
В статье будут рассмотрены такие инструменты как:
Hugo, qbec, kaniko, git-crypt и GitLab CI с созданием динамических окружений.
Вышел новый релиз GitLab с созданием и развертыванием кластеров EKS, поддержкой Crossplane, панелью окружений и многими другими классными фичами!
