Публикуем перевод статьи, которую мы нашли на hackernoon.com. Ее автор, Thiago Miranda, пишет о том, как сделать работу с Git более удобной и эффективной.
Собираем свой flow для git с нуля
6 мин
На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).
Ее основными тезисами были:
- GitFlow противоречит тезису "ветки должны быть короткоживущими".
Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических) - GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого. - GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
- GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)
Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.
Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.
Так что делать-то?
Непрерывная интеграция и развертывание настольных приложений с GitHub Actions
2 мин
Перевод
Из общения с разработчиками настольных приложений мы узнали, что многие хотят узнать, как быстро настраивать рабочие процессы непрерывной интеграции и непрерывного развертывания (CI/CD) для WPF и Windows Forms, чтобы пользоваться многими преимуществами пайплайнов CI/CD, такими как:
Поэтому мы создали пример приложения (GitHub) для демонстрации возможностей DevOps в ваших приложениях, с использованием недавно выпущенного GitHub Actions.
- Обнаружение багов в начале цикла разработки
- Повышение качества и надежности программного обеспечения
- Обеспечение стабильного качества сборки
- Быстрое и безопасное развертывание новых функций
- Быстрое устранение проблем в продакшене за счет новых развертываний
Поэтому мы создали пример приложения (GitHub) для демонстрации возможностей DevOps в ваших приложениях, с использованием недавно выпущенного GitHub Actions.
Вышел релиз GitLab 12.8 с обозревателем логов, NuGet и панелью управления соответствием требованиям
29 мин
Перевод
Новый релиз GitLab 12.8 посвящен подходу «единое место»: для всех ваших логов, пакетов NuGet и контроля за соответствием требованиям. По аналогии с тем, что GitLab — это единое место для всего вашего жизненного цикла DevOps.
Ansible против Puppet
15 мин
Перевод
Ansible и Puppet представляют собой системы управления конфигурациями (SCM), необходимые для построения повторяющихся инфраструктур.
Ansible отличается простотой использования, имеет безагентную архитектуру (не требует установки агента/клиента на целевую систему) и YAML-подобный DSL, написана на Python и легко расширяется за счет модулей. Обычно управляет конфигурацией Linux.
Puppet имеет клиент-серверную архитектуру (периодически опрашивает сервер, чтобы внести в конфигурацию изменения, внесенные администратором сети), написана на Ruby и имеет Ruby-подобный DSL. Это приложение позволяет централизованно управлять конфигурацией ПО, установленного на нескольких компьютерах.
В статье проводится сравнение преимуществ и недостатков этих SCM.
Ansible отличается простотой использования, имеет безагентную архитектуру (не требует установки агента/клиента на целевую систему) и YAML-подобный DSL, написана на Python и легко расширяется за счет модулей. Обычно управляет конфигурацией Linux.
Puppet имеет клиент-серверную архитектуру (периодически опрашивает сервер, чтобы внести в конфигурацию изменения, внесенные администратором сети), написана на Ruby и имеет Ruby-подобный DSL. Это приложение позволяет централизованно управлять конфигурацией ПО, установленного на нескольких компьютерах.
В статье проводится сравнение преимуществ и недостатков этих SCM.
Как не выстрелить себе в ногу, используя Liquibase
8 мин
Никогда не было, и вот опять!
На очередном проекте мы решили использовать Liquibase с самого начала, чтобы избежать проблем в будущем. Как оказалось, не все молодые члены команды умеют его правильно использовать. Я провёл внутренний воркшоп, который затем решил превратить в статью.
Статья включает в себя полезные советы и описание трех самых явных ловушек, в которые можно попасть, работая с инструментами миграции реляционных баз данных, в частности Liquibase. Рассчитана на Java разработчиков уровня Junior и Middle, для более опытных разработчиков может быть интересна для структуризации и повторения того, что, скорее всего, уже известно.
Хорошо подумайте, прежде чем использовать Docker-in-Docker для CI или тестовой среды
6 мин
Перевод
Docker-in-Docker представляет собой виртуализированную среду Docker-демон, запущенную в самом контейнере для сборки образов контейнера. Основной целью создания Docker-in-Docker была помощь в разработке самого Docker. Многие люди используют его для запуска Jenkins CI. Поначалу это кажется нормальным, но затем возникают проблемы, которых можно избежать, установив Docker в контейнер Jenkins CI. В этой статье рассказывается, как это сделать. Если вас интересует итоговое решение без подробностей, просто прочитайте последний раздел статьи «Решение проблемы».
Поднимаем Mercurial на Windows-сервере (с Nginx)
5 мин
Недавно случайно узнал, что BitBucket, где лежат мои Mercurial-репозитории, прекращает поддержку Mercurial: новые репозитории создавать уже нельзя, а существующие будут удалелы с 1.06.2020. Возможные варианты действий: перейти на Git, выбрать один из других сервисов, или настроить хостинг Mercurial на своём сервере. Сервер у меня есть, отказываться от Mercurial и менять привычки как-то не хочется, альтернативы BitBucket мне тоже не приглянулись — поэтому выбрал последний вариант. Задача вроде несложная, вот только сервер у меня под Windows, и, кажется, в процессе настройки я умудрился наступить на максимум возможных граблей. Надеюсь, эта статья поможет кому-нибудь избежать этого и сэкономить время.
Вышел GitLab 12.7 с конвейерами Parent-Child и бета-версией общих обработчиков заданий для Windows
23 мин
Перевод
Вышел релиз GitLab 12.7 — с улучшениями, которые помогут вашим командам и конвейерам (в русской локализации GitLab «сборочные линии») стать более эффективными и результативными. Настройка автоматизации и конвейеров — основа продуктивной работы команд DevOps, и в 12.7 мы предлагаем множество нововведений, которые сделают вашу работу быстрее и эффективнее. Например, конвейеры Parent-Child, группы ресурсов конвейера и бета-версию общих обработчиков заданий (shared runner) для Windows на GitLab.com.
От скриптов к собственной платформе: как мы автоматизировали разработку в ЦИАН
9 мин
На РИТ 2019 наш коллега Александр Коротков сделал доклад про автоматизацию разработки в ЦИАН: чтобы упростить жизнь и работу, мы используем собственную платформу Integro. Она отслеживает жизненный цикл задач, снимает с разработчиков рутинные операции и заметно сокращает количество багов в production. В этом посте мы дополним доклад Александра и расскажем, как прошли путь от простых скриптов к объединению open source продуктов через собственную платформу и чем у нас занимается отдельная команда автоматизации.
Вышел релиз GitLab 12.6 с оценками безопасности проектов и материалами релиза
21 мин
Перевод
Руководителям разработки необходим четкий и понятный обзор состояния безопасности приложения и соответствия требованиям для их проектов. Декабрьский релиз GitLab поможет вам эффективнее отслеживать эти важные параметры.
Arc — система контроля версий для монорепозитория. Доклад Яндекса
11 мин
Системы контроля версий уже давно стали повседневным инструментом разработчика. В больших монорепозиториях требования к ним оказываются весьма специфическими. Из-за этого компании либо адаптируют существующие решения, как это делает Facebook с Mercurial и Microsoft с Git, либо разрабатывают собственные системы: Piper и CitC в Google и Arc VCS в Яндексе.
В докладе разработчик Владимир Кихтенко kikht рассказывает, зачем Яндексу понадобилась собственная система контроля версий и как она работает. Рассмотрим её со стороны рядового разработчика: как получить доступ к исходному коду, отвести ветку для разработки и интегрировать изменения в общую кодовую базу. Заглянем под капот — узнаем про внутреннее представление данных и их отображение в виртуальной файловой системе с рабочей копией. Обсудим трудности при реализации функций VCS в виртуальной файловой системе и при ленивой загрузке данных. Поговорим о том, как обеспечивать надежность серверной инфраструктуры репозитория. В конце можно посмотреть неофициальную запись доклада.
— Всем добрый день, меня зовут Владимир. Вы все слышали выступления о том, что не стоит писать велосипеды. Мой доклад будет с другой стороны баррикад.
В докладе разработчик Владимир Кихтенко kikht рассказывает, зачем Яндексу понадобилась собственная система контроля версий и как она работает. Рассмотрим её со стороны рядового разработчика: как получить доступ к исходному коду, отвести ветку для разработки и интегрировать изменения в общую кодовую базу. Заглянем под капот — узнаем про внутреннее представление данных и их отображение в виртуальной файловой системе с рабочей копией. Обсудим трудности при реализации функций VCS в виртуальной файловой системе и при ленивой загрузке данных. Поговорим о том, как обеспечивать надежность серверной инфраструктуры репозитория. В конце можно посмотреть неофициальную запись доклада.
— Всем добрый день, меня зовут Владимир. Вы все слышали выступления о том, что не стоит писать велосипеды. Мой доклад будет с другой стороны баррикад.
Пробуем новые инструменты для сборки и автоматизации деплоя в Kubernetes
21 мин
Туториал
Привет! За последнее время вышло много классных инструментов автоматизации как для сборки Docker-образов так и для деплоя в Kubernetes. В связи с этим решил поиграться с гитлабом, как следует изучить его возможности и, конечно же, настроить пайплайн.
Вдохновлением для этой работы стал сайт kubernetes.io, который генерируется из исходных кодов автоматически, а на каждый присланный пул реквест робот автоматически генерирует preview-версию сайта с вашими изменениеми и предоставляет ссылку для просмотра.
Я постарался выстроить подобный процесс с нуля, но целиком построенный на Gitlab CI и свободных инструментах, которые я привык использовать для деплоя приложений в Kubernetes. Сегодня я, наконец, расскажу вам о них подробнее.
В статье будут рассмотрены такие инструменты как:
Hugo, qbec, kaniko, git-crypt и GitLab CI с созданием динамических окружений.
Ближайшие события
Введение в GitHub Actions
2 мин
Перевод
В этой статье Senior App Dev Manager Джейсон Джордано (Jason Giordano) покажет нам, как использовать GitHub Actions для создания очень простого CI/CD решения.
GitHub Actions, релиз которого состоялся 13 ноября 2019 года, позволяет легко автоматизировать все ваши рабочие процессы в области программного обеспечения. Вы можете ознакомиться с подробностями здесь.
Также рекомендую ознакомиться с данной документацией перед тем, как решите расширить свое решение.
GitHub Actions, релиз которого состоялся 13 ноября 2019 года, позволяет легко автоматизировать все ваши рабочие процессы в области программного обеспечения. Вы можете ознакомиться с подробностями здесь.
Также рекомендую ознакомиться с данной документацией перед тем, как решите расширить свое решение.
Вышел релиз GitLab 12.5 с созданием кластеров EKS и панелью окружений
22 мин
Перевод
Вышел новый релиз GitLab с созданием и развертыванием кластеров EKS, поддержкой Crossplane, панелью окружений и многими другими классными фичами!
История систем управления версиями
17 мин
Перевод
В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список):
- Первое поколение
- Второе поколение
- Третье поколение
NILFS2 — пуленепробиваемая файловая система для /home
7 мин
Туториал
Как известно, если неприятность может произойти, то она обязательно произойдёт. Наверное, у каждого были случаи, когда случайно был стёрт свежий важный файл, или случайно был выделен и уничтожен текст в текстовом редакторе.
Если вы — хостер или владелец сайта, то, наверное, сталкивались со взломами пользовательских аккаунтов или своего сайта. В таких случаях важно восстановить хронологию, найти способ проникновения и уязвимость, которую использовал злоумышленник.
Для решения подобных проблем прекрасно подойдёт файловая система NILFS2.
Понимание разницы между СI и СD: «если что-то вызывает боль, делайте это почаще»
9 мин
Туториал
Перевод
Disclaimer. Костис Капелонис — Developer advocate (человек, защищающий и отстаивающий принципы программной разработки) Codefresh, первой платформы CI/CD для Kubernetes и контейнеров. Миссия Codefresh «Автоматизировать и упрости всё, от кода до облака». Как инженер-программист, Костис имеет многолетний опыт контейнеризации приложений, построения конвейеров CI/CD и разработки приложений Java. Он живет в Греции и любит кататься на роликах.
Как гласит пословица, «если что-то вызывает боль, делайте это почаще». Непрерывная интеграция — это, по сути, повторение шага интегрирования с высокой частотой, чтобы облегчить вызываемую ею «боль». Статья именно об этом — о «боли» разработки и способах её уменьшить.
Существует много информации о непрерывной интеграции (CI) и непрерывной доставке (CD). Публикации в блогах с помощью технических терминов пытаются объяснить, что означают методологии CI/CD, что они делают и как они могут помочь вашей компании. К сожалению, часто обе эти методологии связывают с конкретными инструментами или даже поставщиками ПО. Типичный разговор на эту тему в компании звучит так:
— Вы используете непрерывную интеграцию в вашей команде?
— Да, конечно, мы используем инструмент X!
Позвольте мне раскрыть вам маленький секрет. Непрерывная интеграция и доставка – это два подхода к разработке кода, которые совершенно не связаны с конкретным инструментом или поставщиком. Несмотря на то, что существуют инструменты и решения, которые могут помочь вам в обеих случаях (например, Codefresh), в действительности компания может практиковать CI / CD, используя только сценарии bash и однострочники Perl. Ээто не очень практично, но, безусловно, вполне возможно.
Поэтому, вместо того, чтобы попадать в общую ловушку объяснения сути CI/CD с помощью инструментов и технических терминов, мы объясним, что представляют собой эти методологии, опираясь на самый важный фактор процесса разработки – людей!
Введение в Git
17 мин
Туториал
Оглавление
Предисловие
1. Настройка git
....1.1 Конфигурационные файлы
....1.2 Настройки по умолчанию
....1.3 Псевдонимы (aliases)
2. Основы git
....2.1 Создание репозитория
....2.2 Состояние файлов
....2.3 Работа с индексом
....2.4 Работа с коммитами
....2.5 Просмотр истории
....2.6 Работа с удалённым репозиторием
3. Ветвление в git
....3.1 Базовые операций
....3.2 Слияние веток
....3.3 Rerere
4. Указатели в git
....4.1 Перемещение указателей
5. Рекомендуемая литература
Предисловие
Git — самая популярная распределённая система контроля версиями.[1][2]
Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).
