За последние пять лет пользовательская база Go утроилась - Go самый быстрорастущий ЯП. В облачных решениях Go сохраняет свою высокую популярность.
Одно из самых заметных изменений в языке с тех пор - это переменная цикла for. Начиная с Go 1.22 переменные, объявленные в цикле for, видны только внутри одной итерации цикла.
Статья Мартина Фаулера, который применяет CI на протяжении более 20 лет.
Continuous Integration (CI) - это практика, при которой разработчики объединяют свои изменения в центральный репозиторий как минимум раз в день. Каждое объединение сопровождается автоматической сборкой и запуском набора тестов. Намного проще интегрировать код, написанный за 2 часа, чем за 2 дня и тем более за 2 недели.
Integration is not a painless process
Интеграция работы нескольких разработчиков — это долгий и непредсказуемый процесс. Pre-Release Integration. Проект разбивается на слабосвязанные unit'ы и на финальном этапе они сливаются в одну кодовую базу. Другой популярный подход - это feature branching. При таком подходе разработчики работают над своими фичами в отдельных ветках и интегрируют их в основную ветку как только их фича завершена.
Вот частые проблемы, если заниматься раздельное разработкой и потом интегрировать:
Идея CI - не "убегать" от основной ветки разработки более чем на несколько часов (максимум день) разработки. Слияние (интеграция) будет в таком случае легким.
Как выглядит процесс разработки при CI у обычного разработчика вроде нас с тобой?
Мы делает git pull главной ветки (mainline). Билдим проект, запускаем тесты, чтобы убедиться, что
у нас рабочая версия (всякое бывает). Вносим правки. Спустя пару часов, перед пушем, подтягиваем изменения
и видим, что коллеги внесли свои коммиты. Мы проверяем все ли ок работает с учетом новых коммитов и, наконец,
пушим изменения в main-ветку. CI агент замечает, что появились новые коммиты в репозитории на сервере и
запускает сборку проекта и его тесты. По итогу нам приходит нотификация, что все выполнилось успешно на сервере.
Использование системы контроля версии.
Автоматизация билда приложения.
Писать self-testing код.
Все разработчики должны вносить правки в mainline по крайней мере один раз в день. По начала это кажется невыполнимым, но просто требует практики. Также такой подход упрощает написание авто-тестов, т.к. внесенные правки небольшие.
Если билд сломался, то чиним его немедленно.
Т.е. все случается в mainline, то билд проекта в этой ветке должен работать. Самым быстрым и простым решением
будет revert последнего комита, который сломал билд. Также на уровне CI Service можно настроить
pre-tested commits (варианты Pending Head могут отличаться по названию). При этом комит попадает
в систему контроля версий строго после успешного билда/тестов.
Билд должен быть быстрым. Разработчики при CI должны получать фидбек максимально быстро. CI цикл (билд/тест) должен случаться не более чем за 10 минут.
Скрывать незаконченные фичи. При таком итеративном подходе, когда мы пушим изменения как только небольшая порция готова и билд не падает неизбежно у нас будут фичи, которые еще рано показывать пользователю. Скрываем их либо с помощью feature flags, либо просто не добавляя в UI.
Integration is primarily about communication
The interplay between self-testing code, Continuous Integration, and Refactoring is particularly strong.
В проекта с открытым исходным кодом лучше подходит feature brunching, т.к. участники плохо знают друг друга