Предотвращаем порчу кодовой базы в iOS-проектах с помощью прекоммит хуков

По мере роста команд и ускорения разработки, поддержание качества кода становится сложной задачей. При разработке под iOS решающее значение имеют последовательный стиль кода, всесторонний линтинг и успешные сборки. Простая ошибка может легко нарушить сборку или привести к некачественному коду.

В этой статье я расскажу о том, как pre-commit Git hook может предотвратить подобные проблемы, автоматизируя проверку кода перед каждым коммитом.

Что такое прекоммит хук?

Pre-commit hook — это скрипт, который автоматически запускается перед коммитом в Git. Он помогает обеспечить соблюдение правил, отклоняя коммиты, не прошедшие определенные проверки. Это гарантирует, что в репозиторий попадает только чистый, отлаженный и функциональный код.

Настройка прекоммит хука для iOS-проектов

Для команды iOS хук до коммита может быть использован для:

1. Ограничения прямых коммитов в защищенные ветки (например, master, development).
2. Запуска SwiftLint для поддержания стиля кода и избежания проблем, связанных с коммитами.
3. Запуска сборки Xcode для выявления ошибок компиляции до фиксации кода.
4. И многого другого.

Как добавить прекоммит хук

1. Создайте файл с названием pre-commit в директории .git/hooks/ вашего проекта.

2. Добавьте следующий скрипт . Этот скрипт ограничивает прямые пуши в критические ветки, применяет SwiftLint и проверяет сборку Xcode.

#----------------------------------------------------------------
# PREVENT YOUR CODEBASE GETTING SPOILED BY DEVELOPERS
# - YOU NEED TO THIS pre-commit file (without any extension) 
#   at ".git/hooks/" folder.
# - THEN TRY TO PUT WRONG STYLED/LINT CODE
#----------------------------------------------------------------

branch="$(git rev-parse --abbrev-ref HEAD)"

#----------------------------------------------------------------
# RESTRICT BRANCHES FROM DIRECT PUSH
#----------------------------------------------------------------
if [ "$branch" = "master" ] || [ "$branch" = "Development" ]; then
  echo "You can't commit directly to $branch"
  exit 1
fi

#----------------------------------------------------------------
# RUN SWIFTLINT  
#----------------------------------------------------------------

# Run SwiftLint
START_DATE=$(date +"%s")

SWIFT_LINT=/usr/local/bin/swiftlint

# Run SwiftLint for given filename
run_swiftlint() {
local filename="${1}"
if [[ "${filename##*.}" == "swift" ]]; then
${SWIFT_LINT} autocorrect --path "${filename}"
${SWIFT_LINT} lint --path "${filename}"
fi
}

if [[ -e "${SWIFT_LINT}" ]]; then
echo "SwiftLint version: $(${SWIFT_LINT} version)"
# Run for both staged and unstaged files
git diff --name-only | while read filename; do run_swiftlint "${filename}"; done
git diff --cached --name-only | while read filename; do run_swiftlint "${filename}"; done
else
echo "${SWIFT_LINT} is not installed. Please install it first from https://www.github.com/realm/SwiftLint"
exit 0
fi

END_DATE=$(date +"%s")

DIFF=$(($END_DATE - $START_DATE))
echo "SwiftLint took $(($DIFF / 60)) minutes and $(($DIFF % 60)) seconds to complete."

#----------------------------------------------------------------
# BUILD XCODE PROJECT & VALIDATE 
#----------------------------------------------------------------
xcodebuild -quiet build -workspace <YOUR WORKSPACE>.xcworkspace -scheme <YOUR PROJECT SCHEME>
if test $? -eq 0
    then echo "Successful build"
else
    echo "Your XCode build is Failed, for scheme "
    exit 1
fi

SwiftLint: ключ к стабильному качеству кода

SwiftLint обеспечивает соблюдение стандартов кодирования и предотвращает стилистические ошибки. Он предлагает две ключевые команды:

• autocorrect: автоматически исправляет такие проблемы, как пробелы, интервалы и длина строки.
• lint: предоставляет предупреждения и ошибки для более сложных проблем, требующих ручного вмешательства.

Запуская SwiftLint как для стейдж, так и для не стейдж файлов, команда может:

• Поддерживать единый стиль кода: все разработчики следуют одним и тем же правилам, что уменьшает количество конфликтов при слиянии и упрощает сопровождение кодовой базы.
• Вылавливать проблемы на ранней стадии: любые стилистические проблемы исправляются еще до того, как они попадают на этап code review.

Проверка сборки с помощью Xcode

Обеспечение успешной сборки проекта перед каждым коммитом может сэкономить часы отладки в дальнейшем. Если сборка в Xcode не удалась, коммит блокируется, что позволяет разработчику немедленно исправить проблему. Этот шаг гарантирует:

• Никакие неработающие сборки не попадают в репозиторий.
• Повышенное доверие к коммитам, поскольку каждый из них прошел базовую проверку.

Зачем нам нужен прекоммит хук?

1. Предотвращение попадания грязного кода в кодовую базу: линтинг перед коммитом гарантирует, что код будет соответствовать лучшим практикам и стандартам.
2. Раннее обнаружение проблем сборки: чем раньше вы поймаете проблему, тем проще и дешевле ее исправить. Обеспечение успешной сборки проекта перед каждой фиксацией предотвращает слияние неработающего кода.
3. Повышение ответственности разработчиков: каждый разработчик становится ответственным за то, чтобы его код был чистым, отлаженным и функциональным еще до того, как он попадет на проверку кода.

Преимущества для iOS-команды

• Более чистый и поддерживаемый код: SwiftLint гарантирует, что код следует согласованным соглашениям, что облегчает его чтение, рецензирование и сопровождение.
• Сокращение числа сбойных сборок: благодаря предотвращению фиксации сборок с ошибками вся команда получает преимущества более стабильной кодовой базы.
• Ускоренное рецензирование кода: автоматизация линтинга и проверки сборки позволяет сосредоточиться на логике и архитектуре кода, а не на проблемах стиля или ошибках сборки.

Можно ли запускать юнит-тесты в прекоммит хуке?

Да, мы можем расширить pre-commit хук, чтобы запустить все юнит-тесты перед коммитом. Используя xcodebuild test, вы можете проверить, что все модульные тесты прошли, прежде чем коммитить код.

Вот как можно изменить скрипт перед коммитом, чтобы включить в него модульные тесты:

# Run Xcode Unit Tests
xcodebuild -quiet test -workspace <YOUR WORKSPACE>.xcworkspace -scheme <YOUR PROJECT SCHEME>
if test $? -eq 0
then
    echo "All unit tests passed."
else
    echo "Unit tests failed."
    exit 1
fi

Добавив это в прекоммит хук, вы гарантируете, что:

• Никакой код, не проходящий тесты, не попадает в репозиторий.
• Код не только чист и скомпилирован, но и функционально корректен в соответствии с существующими тестовыми случаями.

Заключение

Хуки перед коммитом действуют как защитная сетка, гарантируя, что в ваш репозиторий попадает только качественный и функциональный код. Применяя SwiftLint, запуская сборки и опционально выполняя модульные тесты, ваш iOS-проект получит более чистый код, меньшее количество ошибок и более надежные сборки. В быстро меняющемся мире разработки мобильных приложений этот инструмент неоценим для поддержания целостности кода и предотвращения неожиданных сюрпризов в конвейере CI/CD.

Рекомендую ознакомиться с прикрепленным готовым скриптом.

Создание лучшего кода — это то, к чему мы все стремимся. Надеюсь, этот код был вам полезен!

Источник