Разработка
Предотвращаем порчу кодовой базы в iOS-проектах с помощью прекоммит хуков
Хуки перед коммитом действуют как защитная сетка, гарантируя, что в ваш репозиторий попадает только качественный и функциональный код.
По мере роста команд и ускорения разработки, поддержание качества кода становится сложной задачей. При разработке под iOS решающее значение имеют последовательный стиль кода, всесторонний линтинг и успешные сборки. Простая ошибка может легко нарушить сборку или привести к некачественному коду.
В этой статье я расскажу о том, как pre-commit Git hook может предотвратить подобные проблемы, автоматизируя проверку кода перед каждым коммитом.
Что такое прекоммит хук?
Pre-commit hook — это скрипт, который автоматически запускается перед коммитом в Git. Он помогает обеспечить соблюдение правил, отклоняя коммиты, не прошедшие определенные проверки. Это гарантирует, что в репозиторий попадает только чистый, отлаженный и функциональный код.
Настройка прекоммит хука для iOS-проектов
Для команды iOS хук до коммита может быть использован для:
- Ограничения прямых коммитов в защищенные ветки (например, master, development).
- Запуска SwiftLint для поддержания стиля кода и избежания проблем, связанных с коммитами.
- Запуска сборки Xcode для выявления ошибок компиляции до фиксации кода.
- И многого другого.
Как добавить прекоммит хук
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 не удалась, коммит блокируется, что позволяет разработчику немедленно исправить проблему. Этот шаг гарантирует:
- Никакие неработающие сборки не попадают в репозиторий.
- Повышенное доверие к коммитам, поскольку каждый из них прошел базовую проверку.
Зачем нам нужен прекоммит хук?
- Предотвращение попадания грязного кода в кодовую базу: линтинг перед коммитом гарантирует, что код будет соответствовать лучшим практикам и стандартам.
- Раннее обнаружение проблем сборки: чем раньше вы поймаете проблему, тем проще и дешевле ее исправить. Обеспечение успешной сборки проекта перед каждой фиксацией предотвращает слияние неработающего кода.
- Повышение ответственности разработчиков: каждый разработчик становится ответственным за то, чтобы его код был чистым, отлаженным и функциональным еще до того, как он попадет на проверку кода.
Преимущества для 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.
Рекомендую ознакомиться с прикрепленным готовым скриптом.
Создание лучшего кода — это то, к чему мы все стремимся. Надеюсь, этот код был вам полезен!
-
Новости2 недели назад
Видеозвонки с Лили, Приключения и пианино — обновления Duolingo
-
Новости2 недели назад
Видео и подкасты о мобильной разработке 2024.39
-
Разработка2 недели назад
Android сломался или я чего-то не понимаю? — Обсуждение на Reddit
-
Статьи2 недели назад
Как технический долг испортил приложение Sonos