Git pre-commit hooks для DevOps

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт, IT спільното!

Мене звати Дмитро Сірант, вже 4 роки я працюю на позиції СТО компанії OpsWorksCo. За цей час ми стали AWS Advanced Consulting Partner, суттєво розширили експертизу та зміцнили нашу команду. Мій попередній досвід DevOps-інженера дає можливість глибоко оцінити проєкт, тісно співпрацювати з командою. Я і досі долучаюсь до проєктів компанії, щоб удосконалювати технічну експертизу, бути в курсі сучасних тенденцій. Додавайтесь до мене в LinkedIn, буду радий знайомству.

Ця публікація буде корисна DevOps та Cloud інженерам, а також всім, хто цікавиться сучасними технологіями та прагне постійного розвитку. Підписуйтесь на Youtube-канал нашої компанії @DevOpsTalksAtOpsworks та долучайтеся до онлайн вебінарів, які ми проводимо.

Як багато від Developer має бути у DevOps

Вибачте за трохи холіварний топік, але перш ніж перейти до суті цієї статті, мені необхідно пояснити один момент. Я належу до тієї категорії людей, яка вважає, що DevOps — це не роль, а підхід або набір практик, які мають бути побудовані в компанії. Цікаво почути, хто з читачів розділяє моє бачення? Пишіть у коментарях як ви розумієте DevOps.

Отже, я уявляю собі DevOps Engineer як людину, яка впроваджує ці практики та вибудовує взаємовідносини між різними командами. Проблема в тому, що у такої людини має бути досвід з обох світів (Development та Operations) і вона аж ніяк не може бути Junior або Middle.

Так сталося, що переважна більшість моїх колег прийшли до DevOps зі світу Operations. Іншими словами, вони починали свою карʼєру як System Administrators, Linux Administrators, Network Engineers або Support Engineers. Щоб отримати досвід у розробці, вони роками будували pet-проєкти, використовуючи різні мови програмування, вивчали патерни OOP та Software Architecture від колег-розробників. Можна сказати, що ще до появи DevOps вони не цуралися зазирати у код додатка, а тим паче не казали, що це не їхня відповідальність, щоб він краще працював в продакшн-оточенні. Завдяки такому підходу вони змогли набути необхідного обсягу знань, щоб комунікувати з розробниками спільною мовою. Але чи можна очікувати, що спеціаліст, який інколи займався кодингом як хобі, матиме той самий досвід що і розробник, який займається цим постійно? Я вважаю, що ні, і є багато речей, яким ми можемо навчитися в розробників.

Що таке git pre-commit hooks та навіщо вони в DevOps

Коли команда розробників працює з системою контролю версій (зазвичай це git, але якщо хтось має на проєктах mercurial або subversion, маякніть у коментарях, хочу дещо запитати), то бажано не допускати поганих комітів (code style, syntax errors), щоб не навантажувати непотрібною роботою CI/CD або колег, які роблять code review. По суті, git pre-commit hooks є послідовністю команд, що виконуються перед здійсненням git commit. Якщо виконання цих команд завершиться неуспішно, коміт не буде здійснений, і розробнику буде запропоновано внести зміни. На цьому сайті ви знайдете велику кількість скриптів та інструкції з їх налаштування.

То до чого ж тут DevOps? Одним з рекомендованих аспектів цього підходу є описування інфраструктури за допомогою коду, так званого IaC (або «Інфраструктура як код»). Це може бути Ansible, Terraform, CloudFormation, Kubernetes manifests, Helm templates, або навіть опис процедури CI/CD у вигляді YAML-файлу. Все це код, який ми тримаємо в системі контролю версій, який так само перевіряється на code review, покривається тестами та обробляється на етапі CI/CD.

Подивімось, які pre-commit hooks є в наявності для інструментів, які асоціюються з повсякденною роботою DevOps-інженера.

Які git pre-commit hooks я використовую

У жодному разі не буду стверджувати, що це вичерпний список того, що може вам знадобитися, я завжди відкритий до нових ідей і чекаю від вас щось цікавеньке в коментарях.

В цьому репозиторії зібрані всі хуки, які є частиною проєкту pre-commit-hooks. Тут я знайшов корисними для себе наступні перевірки:

  • end-of-file-fixer — перевіряє і виправляє, щоб кожен файл закінчувався новим рядком і лише одним;
  • trailing-whitespace — видаляє пробіли у кінці кожного рядка файлу;
  • check-merge-conflict — перевіряє файли на наявність маркера merge-conflict;
  • check-symlinks — перевіряє, чи відсутні биті сімлінки;
  • detect-private-key — перевіряє, чи не комітимо ми приватні ключі;
  • mixed-line-ending — призводить файли до консистентного визначення кінця рядка.

Це лише маленька частина наявних в репозиторії хуків, раджу перевірити чи є там щось цікаве для вас.

Цей проєкт розвиває відомий амбасадор Terraform Антон Бабенко, і в ньому ви знайдете хуки, які стосуються Terraform та Terragrunt, а саме:

  • terraform_fmt, terragrunt_fmt — форматування коду;
  • terraform_docs — генерація документації на основі вашого коду terraform;
  • terraform_providers_lock — генерація та оновлення provider_lock;
  • terraform_tflint — лінтер, який перевіряє синтаксис вашого коду terraform;
  • terraform_tfsec — статичний аналізатор коду terraform, виявляє потенційні проблеми з безпекою при розгортанні інфраструктури з вашого коду;
  • tfupdate — оновлення версій модулів та провайдерів;
  • infracost_breakdown — показує розрахунок вартості інфраструктури або змін до інфраструктури за допомогою infracost.

Ви можете знайти інші репозиторії, в яких зібрані хуки під різноманітні мови програмування або навіть створити свій, який буде відповідати вашим вимогам.

Якщо ви не бачите сенсу у створені й підтримці свого репозиторію, можна додати будь-які скрипти у конфігурацію проєкту. Наприклад, на одному з проєктів у мене є ось така перевірка для helm template:

- repo: local
  hooks:
    - id: backend-helm-linter
      name: inline-helmlint-with-bash
      entry: /bin/bash -c 'for env in dev qa prod; do helm lint backend/ -f backend/secrets-$env.yaml -f backend/values-$env.yaml; done'
      language: script
      files: \.((ya?ml)|(tpl))$
      require_serial: true

Інсталяція і налаштування

Я не думаю, що у когось виникнуть проблеми із встановленням та налаштуванням pre-commit, процедура досить прозора і налічує лише три кроки:

  1. Встановити pre-commit, наприклад, на Mac це робимо як brew install pre-commit.
  2. Створити файл конфігурації .pre-commit-config.yaml у корені вашого проєкту і додати в нього необхідні вам перевірки.
  3. Активувати ваші хуки, виконавши команду pre-commit install.

Виконавши ці нескладні кроки при запуску git commit, лише змінені файли будуть перевірятися згідно з вашими правилами. Якщо треба перевірити увесь проєкт, це можна зробити, виконавши pre-commit run —all-files.

Підсумок

Якщо ви новачок, сподіваюся що ця стаття не лише відкрила для вас новий інструмент, але й спонукала поглибити свої знання у сфері розробки. Чим більш розширений ваш кругозір, тим більш цінним гравцем ви станете для команди, і тим більше можливостей відкриється на вашому кар’єрному шляху. Я пишаюсь, що в нашій компанії багато спеціалістів, які постійно розвиваються та діляться своїм досвідом. Якщо ви саме така людина, тримаймось на звʼязку і одного дня це може перетворитися у щось цікаве.

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному5
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за статтю і за посилання!
Може щось собі цікавого знайду.

Дякую що популяризуєте корисні практики Сам намагаюся використовувати pre-commit де тільки можливо. Повністю згоден з тим що поняття DevOps/DevOps Engineer наразі викривлені

Интересная статься, интересовался пре-коммит хуками в рамках этой статьи

blog.developer.atlassian.com/stop-foxtrots-now

Что вы думаете на счет серверных хуков для предотвращения мержей сломанных пул-реквестов? Заранее спасибо

Ваше посилання на статтю не працює, має бути якась публічна жінка.

Стосовно серверних хуків, не бачу нічого поганого у їх використанні. Ми налаштовували для gitlab і окрім згаданого вами варіанту про зламані MR ми ще додавали перевірку на наявність Jira ticket у описі. На відміну від client side їх не можливо проігнорити.

Здравствуйте. Да, я по ошибке указал неверную ссылку, ссылка исправлена

Дякую за посилання, отримав нові знання. Ніколи не замислювався про існування такої проблеми. Як на мене, валідне використання pre-commit хуків на стороні сервера у цьому випадку.

Наша ДС команда почала використовувати пре-коміт хуки в своїх репозиторіях. А от наш девопс ~виліз із печери і~ цьому противиться: каже, що це дуже небезпечно. Я поки що не зміг добитися пояснення, що саме там небезпечного, або ж чим це більш небезпечно ніж, скажімо, використовувати будь-які оупен-сорс ліби. Тим не менш, чи є якісь знані security concerns для pre-commit hooks та для pre-commit hooks всередині CI pipelines?

Тут було б цікаво почути його аргументацію, але давайте поміркуємо.
Єдине що приходить на думку — це так звана supply chain attack, тобто якщо ми використовуємо зовнішній репозиторій в якому описані дії які ми робимо з нашим кодом то у разі компроментації — може трапитись щось погане. Цьому дійсно треба приділяти увагу, а саме:
1. Використовуємо відомі і підтримувані репозиторії.
2. Використовуємо теги а не main ref
3. Найбільш критичне що може статися — це витік даних назовні, в мене стоїть Little Snitch на Mac який блокує по дефолту будь яку нову комунікацію назовні.

Якщо є ще якісь потенційні проблеми — пишіть, обсудимо.

Цікава тема, але «Це ж було вже». Десь місяць чи два тому була стаття про ці ж самі пре-коміт хуки. У мене навіть посилання на репозиторій вже показалось відкритим. Але у будь якому випадку дякую

Тут ніколи не вгадаєш. Я теж дуже полюбляю «унікальний» контент, який ще ніхто і ніде не писав але чим більше читаєш тим менше бачиш таких можливостей. Можливо не треба писати статтю і потім відкладати публікацію на місяць лише по причині, що вже було дві статті минулого місяця :)

Скільки часу займають ваші хуки?
Чи є скарги від розробників на тривале виконання / необхідність виправляти бранчу (наприклан конфлікти) до того, як вона буде остаточно готова до ревью?
Розглядали варіанти переносу статичних перевірок на рівень CICD?

Зазвичай менше 2-3 секунд, інколи до 5-7. Справа в тому, що вони виконуються до того коду, в якому були зміни і дуже швидкі по своїй суті — літери і форматери коду не потребують запуску вашого проекту і виконання тестів. Вони в жодному разі не мають заміняти перевірки, які ми робимо на етапі CI, які більш комплексні і перевіряють вже весь код.
Ні, скарг не було, тим паче, що це налаштовується на стороні розробника — якщо йому ну прям зовсім не заходе — він може вимкнути персонально у себе.

Странно слышать такие жалобы от девелоперов, какбе это их прямая обязанность — в репозиторий не должен попадать сломанный код на котором не проходят тесты

Підписатись на коментарі