Команда GitLab стремится к повышению производительности и степени удовлетворённости разработчиков. Релиз 13.6 содержит все необходимые ингредиенты, которые помогут вам достичь этого и, возможно, чего-то ещё! Мы надеемся, что вам пригодятся основные фичи релиза, а также ещё более 60 новых фич и улучшений, добавленных в этом релизе.
Управление миграциями баз данных для нескольких сред и команд может быть достаточно сложной задачей. В этой статье описывается, как сочетание Git, контейнеров и клонов баз данных используется для реализации доставки в среды разработки, тестирования и стейджинга за считанные секунды.
Хотя Git и так часто используется в сочетании с контейнерами баз данных, описанный здесь подход все же вводит два новых элемента. Вместо того, чтобы воспроизводить базы данных из бекапов или создавать из источника данных, мы клонируем идентичные безопасные среды производственных баз данных и доставляем их в течении секунд. Клоны баз данных доступны для записи и позволяют легко внедрять маскирование данных и синтетические тестовые данные. Второй элемент - это файл манифеста сценариев, используемый при создании и применении персонализированных сценариев миграции.
Разработчик может работать с клоном производственной базы данных в функциональной ветке - сценарии для этой ветки применяются автоматически. В то же время команда тестирования может работать в релизной ветке с идентичным клоном производственной базы данных - для нее применяется набор релизных сценариев. На каком-нибудь конвейерном стейдже можно протестировать откат релизной ветки с третьим идентичным безопасным клоном производственной базы данных, благодаря автоматическому применению сценариев обновления и отката.
Эта статья берет за основу SQL Server, но эти методы также поддерживаются Postgres и MySQL.
Вышел релиз GitLab 13.5 со сканированием безопасности мобильных приложений, вики-страницами групп, общим реестром пакетов и многими другими классными фичами!
refspec во время git fetch ускоряет шаг клонирования в 100 раз. 
Эксперт OTUS - Владимир Дроздецкий приглашает всех желающих на бесплатный вебинар, в рамках которого он подробно расскажет о программе курса "DevOps практики и инструменты" и ответит на интересующие вопросы. А прямо сейчас, по устоявшейся традиции, делимся с вами интересным переводом.
Недавно я общался с разработчиками из Humanitec (это Continuous Delivery-платформа для Kubernetes). Humanitec интересен тем, что вопреки современным тенденциям, он не основан на GitOps.
Лично я большой фанат GitOps, потому что он позволяет строить CI/CD без сложных инструментов с использованием только Git и декларативного описания конфигураций. Но несмотря на то, что я недавно написал статью "11 Reasons for Adopting GitOps" (11 причин для внедрения GitOps), в своей практике я неоднократно сталкиваюсь с ограничениями этого подхода. Беседа с ребятами из Humanitec побудила меня написать об этом негативном опыте для того, чтобы предоставить вам более объективную картину GitOps и поговорить об альтернативных подходах.
Всем привет! Меня зовут Станислав Лукьянов. Я работаю в компании GridGain. Сегодня я хотел поговорить о том, как мы поддерживаем старые версии в Git.
До 2020 года я работал конструктором (разрабатывал электронику и электрику). Сейчас я сменил сферу деятельности, но считаю важным поднять вопрос, который возник в свое время пока он совсем не выветрился из головы. В статье затронута важность разработки стандартов в команде hardware разработчиков, а также приведен пример одного из стандартов для ведения репозитория для сборку.
/target // скрипты для сборки ядер
/toolchain // скрипты для сборки gcc, musl и прочих инструментов сборки
/feeds // дополнительные репозитории с приложениями
/package // скрипты для сборки приложений
...
В GitLab мы всегда думаем о том, как помочь пользователям снизить риски, повысить эффективность и скорость поставки на вашей любимой платформе. В этом месяце мы добавили немало полезных новшеств, которые расширяют возможности безопасности, снижают количество уязвимостей, повышают эффективность, упрощают работу с GitLab и помогают вашей команде поставлять фичи ещё быстрее. Мы надеемся, что вам пригодятся основные фичи релиза, а также 53 другие новые фичи, добавленные в этом релизе.
Большинство из нас, подмечая очередной новый термин в IT блогосфере или конференции, рано или поздно задается подобным вопросом: “Что это? Очередное модное слово, “buzzword” или действительно что-то стоящее пристального внимания, изучения и обещающее новые горизонты?” Точно также вышло у меня и с термином GitOps некоторое время назад. Вооружившись множеством уже существующих статей, а также знанием коллег из компании GitLab, я попытался разобраться, что же это за зверь, и как его применение может выглядеть на практике.
Автоматизация рабочего процесса Java-проекта с помощью модифицированной модели ветвления Gitflow
Разделение функций с использованием изолированных ветвей позволяет вам решить, какие функции включать в каждый релиз. Компромисс здесь может заключаться в сложных слияниях.
Как все знают, монорепозиторий - это несколько частей проекта (приложения, сервисы, библиотеки и т.д.), которые хранятся в одном репозитории. Плохо это или хорошо - не тема данной публикации. Но все же упомяну некоторые причины по которым я решил их использовать.
В скриптах деплоймента (или в моем случае еще и в настройках GitLab репозитория), нужно сформировать токены/ключи доступов к докер реджистри, кубернетесу, разным кластерам и т.д. И если у вас пару сервисов, то это не проблема, но если сервисов 15-20, то это весьма болезненный процесс. Особенно, когда настройки кластера меняются и нужно эти изменения вносить во все репозитории.
В определенных случаях среди нескольких сервисов, можно выделить общий код, который можно переиспользовать (описание интерфейсов, утилиты и т.д.) и особенно важно на самом старте проекта, когда эти общие куски кода только формируются не тратить время на коммиты в отдельные репозитории, если нужно всего лишь добавить поле в общий интерфейс.
После того как мы перешли на монорепозиторий появилось еще несколько преимуществ, без которых, в принципе, тоже можно жить, но все равно это был приятный бонус.
И вот мы решили использовать монорепозиторий, но с чего начать и как все организовать?
Вы используете семантический подход к управлению версиями? Вы используете gitflow? Скорее всего, вы знакомы с процессом корректировки версий, создания веток, слияния с master/dev, повторной корректировки версий, борьбы с конфликтами слияния,…
В этой статье я кратко объясню процесс выпуска, который мы, по сути, используем для наших библиотек, и то, как мы его автоматизировали. Обычно мы используем подход CI/CD, используя номера сборок, но для наших библиотек мы решили использовать семантическое управление версиями. Я столкнулся с утомительным процессом выпуска, который сопровождает это в нескольких компаниях, и теперь я наконец нашел решение.
Я разработчик игр и мобильных приложений. Я написал немало кода на C++ и Swift. И, как и многие из вас, я пользуюсь системами контроля версий, в частности, гитом.
Гит имеет максимально функциональный command-line интерфейс и десятки если не сотни приложений для работы с ним локально при помощи графического интерфейса, которые умеют выполнять только часть функционала гита. Беда в том, что я пишу код уже 10 лет, но никак не нашел идеальный (подходящий для меня) git GUI клиент. Пример: недавно вышел Github Desktop. Я его использовал до тех пор, пока мне не понадобилось сделать checkout на конкретный коммит. И я испытал уже привычную боль от того, что данное приложение так делать не умеет. И вновь вернулся в терминал (с автодополнением для гита). И такие вещи есть в каждом GUI приложении для гита. Однако, я сюда пришел не критиковать их. Уверен, что вы и без меня имеете много претензий к этим приложениям. Я долго думал о том каким должно быть идеальное git GUI приложение. Это были мимолетные обрывки желаний, из которых трудно собрать что-то цельное. И совсем недавно эти обрывки мыслей у меня собрались в единую картину. Ниже я опишу это в формате ТЗ (технического задания) в максимально понятной форме.