Git pre-commit hooks для DevOps

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до 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.

Підсумок

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