👉 Делаем дебажное правило, которое позволяет запускать пайплайн на любой ветке по API. В GitLab CI выглядит примерно так:
rules:
# Тут будут основные правила запуска
- if: $PIPELINE_TYPE == "DEBUG_MR" # это правило позволяет запустить пайплайн на любой ветке, без создания МРа через API
Мы можем навешивать такие условия на нужные нам Job, чтобы, например, не гонять весь пайплайн целиком или чтобы обходить правила пайплайнов, которые должны запускаться только на релизной ветке.
👉 Используем конструкцию с echo, чтобы понять, с какими аргументами запустили программу. Например, вы в Job вычисляете какие-то параметры, чтобы потом запустить Gradle. У Gradle, как вы знаете, логи ублюдские, поэтому проще узнать, а с каким параметром мы вообще его запустили. По умолчанию в логах Job не будет этой информации, однако вот такая конструкция легко позволяет ее получить:
echo "./gradlew some-task $args"
./gradlew some-task $args
👉 Канарейка. Внезапно, да, можно использовать канарейку и в CI/CD. Может возникнуть вопрос, нахера в CI/CD-то оно нужно. Дело в том, что на большом проекте, когда у вас орда разрабов, которые что-то постоянно пушат и создают МРы, вам желательно (но не обязательно) не косячить в пайплайнах. Мы помним, что при обновлении пайплайнов не все сразу перейдут на новую версию.
Поэтому, когда вы, например, добавляете новую экспериментальную Job, очень крутой подход — сделать эту Job под флагом. Флагом, который вы в случае чего можете быстро выключить в консоли CI системы:
rules:
- if: $FEATURE_NEW_JOB_ENABLED == "true"
👉 Проектируйте логи. В разработке CLI нужно проектировать то, что вы будете выводить в консоль, также тщательно, как вы проектируете UI для приложений. Ничего лишнего, только самое нужное. Помимо этого, у вас должна быть возможность включить прям максимум логов, чтобы отследить каждый шаг.
Меня очень спасает подход, когда я эти дебажные логи могу включить не только через флаг, но и через ENV переменную. Это нужно, чтобы я мог просто в консоли CI быстро добавить эту ENV переменную и сразу везде, без изменения пайплайнов, включить логи и посмотреть, где проблема.
👉 База. Ну и, разумеется, очевидные советы, вроде: используйте cat и echo в скриптах, чтобы понимать, что происходит, в bash-скриптах не забывайте использовать
set -x, чтобы видеть все команды, не забывайте проверять наличие файлов перед их использованием. И самое главное, ни при каких обстоятельствах, чтобы не происходило с вашей карьерой, не ешьте желтый снег!