TestingStage'17 - конференция №1 для тестировщиков. Успей купить билет по цене early bird до 26.04.

Як ми створювали PHP Continuous Integration Workflow в нашій команді

Image via Shutterstock.

Почалось усе з того, що в компанії піднялось питання knowledge exchange для команд, які рознесені по всьому світу. Виникла проблема: команди кожного разу придумують велосипеди і пишуть по суті один і той же код.

На той час в компанії вже була спільна поштова конференція по Drupal, але користі від неї було мало. Також була в наявності деяка база минулих проектів, але жодної інвентаризації того, що в них там було створено, не існувало. Щоб було більш зрозуміло: компанія, по суті, створювала проекти, написані на PHP/Drupal, часом на Symfony2.

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

Як тільки ми обломались із інвентаризацією минулих проектів, я приступив до реалізації Continuous Integration, яка б дозволила привнести в компанію певний рівень стандартизації робочого процесу.

Ідея — додати автоматичну перевірку коду на стандарти, якими, як відомо, володіє Drupal спільнота.

Перша реалізація — додати перевірку коду PHP CodeSniffer кожного разу, як відбувається здача окремого завдання розробником.

Для цього ми використали вже існуючий на той час функціонал GitHub Pull Request. Для тих, хто не знайомий з даною технологією — перш ніж додати зміну коду в головну гілку з допомогою PR є можливість переглянути внесені зміни (manual code review).

Насправді додання цієї ручної перевірки, хоч воно було реалізовано першим, виявилось найскладнішим завданням, над втіленням якого ми працюємо досі. Мотивувати людей переглядати код інших розробників було досить складно. Але благо — в нас у команді виявилось два маніяки, для яких цей процес важливий.

Ми поставили на потік перевірку одне одного і почали вводити дану культуру в інші команди.

Було боляче. На цьому етапі ми чітко почали виявляти справжній рівень знань наших розробників. Звісно, наявність злих сеньйорів, які постійно дістають коментарями до написаного, сильно не змінить підхід до розробки. Все, чого можна досягти у такий спосіб — це змусити всіх розробників вас ненавидіти.

Але є і плюс від процесу ручної перевірки коду: на цьому етапі ті, хто робить цю перевірку, починають розуміти масштаб проблеми в командах і те, які складності приходиться долати в процесі розробки.

В той період головним надбанням стало створення домовленостей:
— які технології ми повинні використовувати для переносу конфігурацій
— як ми повинні уніфікувати середовища розробки (тут ми всі пересіли на Vagrant)
— як ми повинні діяти із базою даних, коли в ній вже присутні матеріали, додані клієнтом
— як розбивати завдання і чому вони мають бути короткими, а не довгими.

Вибір технологій — це те, що постійно змінюється. Думаю, що це не тільки в Drupal світі, але і в будь-якому середовищі програмування. Клієнти постійно хочуть чогось нового. Технології не стоять на місці. Але певні речі вдалось уніфікувати. Ну, принаймні для тих команд, які були в нашому полі зору.

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

Для тих, хто не так близько: інсталяційний профіль — це набір команд, який виконується в момент розвертання збірки Друпал на хостінг. За його допомогою можна вказати, які модулі, які теми і конфігурації потрібно увімкнути на етапі інсталяції, щоб отримати інтернет-проект, готовий до роботи.

Що дає прив’язка до профілю?

Прив'язавшись до інсталяційного профілю, ми повністю перейшли на Code Driven Development — дана технологія майже повністю виключає можливість робити зміни в базі даних не через код.

Приклад початку роботи над завданням:

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

Дивлячись сьогодні на той процес, розумію, наскільки далеко ми пішли зараз із нашим CI. Але все по черзі.

На той час у нас була ручна перевірка коду на GitHub. І виникла ідея додати деякої автоматизації, бо більшість коментарів на той час були такі:
— додай docblock для функції
— додай docblock для файлу
— виправ стиль коду згідно зі стандартами
— виправ реалізацію згідно з ^^^

В основному ми стопорились саме на стандартах, бо багато розробників не дотримувались їх, і тут майже не було залежності від рівня — лажали всі. І це було зрозуміло: щоб бути мотивованим на дотримання стандартів, потрібно бути активним учасником спільноти Друпал і публікувати свої модулі на drupal.org. Лише тоді приходить розуміння, для чого це, лише тоді зустрічаєшся із тим, що твій модуль не приймають модератори, бо ніхто не хоче дивитись на код, який читати неможливо.

А нам саме це і було потрібно — створити мотивацію в наших співробітників, щоб вони публікувати свій код в спільноту — це і є code sharing, якого ми прагнули досягти.

Перші кроки автоматизації

Почати ставити команду на CI — нетривіальне завдання. Перший крок буквально міняє всі правила гри. В нашому випадку це було написання мною скрипта reinstall.sh

Спочатку все було на банальному shell
— вбити базу даних
— скинути налаштування до базових
— запустити інсталяцію Друпал
— оновити файли із Stage локально.

Цей скрипт було залито разом із проектом, і кожен почав його використовувати. Як бачите, про сканування коду на предмет стандартів тоді ще не йшлося. Все відбувалось малими кроками.

Віртуалізація + Vagrant

В наших командах були, є і будуть розробники, які працюють на MacOS, Windows OS && Linux OS. І потрібно було розробити таку систему, щоб уникнути проблему конфліктів і різниці середовищ. Ми прийняли дуже нелегке рішення — перейшли на віртуалізацію.

Стартанули із puphpet.com, по якому навіть провели кодспринт, щоб привести проект в вигляд, необхідний для наших потреб. В результаті ми отримали уніфікацію середовищ розробки за однієї проблеми — скрипти puppet, де були зібрані віртуальні конфігурації puphpet.com, не відрізнялись стабільність в тривалій перспективі — їх необхідно було постійно доробляти, щоб встигати в ногу за новими версіями програм. З часом ми перейшли на іншу систему, базовану на ansible provisioner.

Go Jenkins!

Для автоматичної перевірки коду ми використали Jenkins. Вибір сам напрошувався: були навички написання коду на Java і деяка практика використання цієї системи для автоматизації обслуговування серверів. Був використаний, а потім і дописаний плагін GitHub Pull Request Builder, який дозволяє запускати Jenkins job по події створення нового Pull Request в GitHub проекті.

Наступні кроки були справою техніки — створити скрипт, який буде запускати PHP CodeSniffer із стандартами Друпал для коду, який знаходиться в новому Pull Request.

І тут ми вперлись в проблему: як ядро, так і 100% контріб модулів, які ми використовуємо в кожному проекті, не проходять стандарти Друпал.

Це був перший шок, який дав нам зрозуміти, що доведеться змінювати всю суть розробки. В цей час ми вирішили відділити наш код від коду, який ми перевикористовуємо. І тільки наш код перевірявся на стандарти — ядро і contrib модулі ми пропускали. Це призвело до створення структури проекту, якою ми користуємося і досі.

Як для модулів, так і для шаблонів тем ми перейшли на структуру
— sites/all/modules/contrib
— sites/all/modules/custom
— sites/all/modules/features
— sites/all/modules/patched
— sites/all/modules/patches
— sites/all/themes/contrib
— sites/all/themes/custom

Відповідно в цій структурі сканування на стандарти коду відбувається лише для тек custom, бо тільки цей код пише команда.

Це вже кінцева структура. Бо теки patched && patches з’явились пізніше. Дану конвенцію ми розробляли кілька місяців, тим самим змусили всіх розробників публікувати патчі до contrib модулів на drupal.org.

Для чого це?

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

Таким чином ми вирішили проблему активності користувачів у спільноті — ми створили правило: якщо змінюєш модуль, добийся того, щоб латку було прийнято, і в наступній версії модуль знову повернувся з теки patched в теку contrib. Ну, а додатковим бонусом тут було те, що профілі наших розробників стали рости (продавці тепер мають, чим заманювати клієнтів), і досвід розробників разом з цим.

Project build

Наступний крок розвитку — створення project build для кожного Pull Request. До цього ми змушені були прийти, рано чи пізно.

Проблема, яка мотивує на це, — стара, як світ. Розробник на своєму локальному середовищі все реалізував, все у нього працює, код зливається в головну гілку репозиторія, робиться deploy на Stage — і, вуаля, щось не працює.

Причина: той самий розробник забув про конфігурацю. І проблема не в тому, що потрібно виправляти, а в тому, що час виконання завдання збільшується — deploy на Stage відбувається не кожного дня, і проблему можна навіть пропустити, бо минає якийсь час.

Тут нам стало цікаво отримати збірки проектів, таким самим чином як це роблять розробники десктопного програмного забезпечення.

В нагоді став скрипт reinstall.sh, який на той час вже мав кроків з 10.

Все, що залишилось — це реалізувати Jenkins job, яка буде запускати цей скрипт на окремому сервері із кодом, який є в наданому розробником Pull Request, і інсталювати проект, надаючи унікальне посилання для доступу до тестування цього проекту.

Це змінило наш процес глобально. Як тільки ми релізували перший build, виявилось, що тепер немає необхідності робити QA на Stage — ми можемо відправляти їх на тестування білдів ще до того, як код заходить в master.

Перша реалізація системи, яка створювала білди для проекту, зайняла у нас майже тиждень. Інсталяція Jenkins + LAMP + PHP CodeSniffers + JShint + налаштування всього цього, щоб працювало разом із проектом GitHub.

Knowledge Exchange via QA

Першочергова проблема, яка стояла перед нами — обмін досвідом — так і не була вирішена аж до моменту, коли ми заборонили PR merge без проходження всіх тестів на стандарти коду. І тепер, при наявності готових build, у нас з’явилось нове правило — віддавати код на ручну перевірку кожен раз іншому учаснику команди. Це викликало деякі баталії щодо стилів, але з часом вони припинились, бо люди просто домовились, як ми пишемо.

Але головне — тепер в команді не було випадків, коли той чи інший функціонал був відомий лише одному учаснику, який його реалізовував — тепер є людина, яка переглядала код реалізації і шукала в ньому помилки, і був QA, котрий тестував функціональність реалізації одразу — тут же, в PR, який ще не зайшов в master гілку репозиторія.

Це призвело до того, що команди автоматично стали писати Steps for review для кожного Pull Request. І ці кроки змушений був писати той розробник, який реалізовував завдання.

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

На цьому етапі прості розробники стали розуміти, що реалізація тієї чи іншої задачі включає в себе логіку тестування, і з часом ми помітили, що реалізації ставали чим далі, тим більш елегантними — розробники стали більш розуміти бізнес процеси і UX.

Народження CIBox

Прийшов наступний проект, на якому ми теж хотіли використовувати CI. Налаштовувати новий сервер для нового проекту руками вже дуже не хотілось. Так ми прийшли до ansible.

Всі кроки інсталяції і всі конфігурації з першого проекту були за кілька днів зашиті у скрипт для ansible, який давав змогу налаштувати сервер не за тиждень, а за 12 хвилин, а потім за кілька годин зміни ключів доступу в налаштуваннях Jenkins ми мали змогу отримувати перші білди для нового проекту.

Даний ansible пакет було названо CIBox (Continuous Integration toolBox). Лише через півтора роки ми вирішили зробити його opensource.

Оновлення і обслуговування CI

Сама система Continuous Integration і весь набір складових — доволі складна річ. І рівень тих, хто її обслуговує, повинен бути відповідним. Ці люди повинні добре знати як Development, так і Operations, іноді навіть більше Operations.

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

Як не дивно, проблема вирішилась тим, що ми отримали перші бонуси від проектів, реалізовані із CI — деякі team lead і розробники зацікавились CI і захотіли всі свої наступні проекти робити лише на ньому.

Бонуси

— якість коду,
— відсутність збоїв deployment,
— зручність manual code review,
— стандартизація і поява ситуацій, коли модулі з теки custom раптом почали підходити і для наступних проектів, бо вони стали більше відповідати бізнес логіці, а не конкретному завданню,
— зниження тривалості UAT (User Acceptance Testing) періоду.

Останній пункт вже зацікавив бізнес. В одному з проектів згідно estimate у нас за звичкою було заплановано 4 тижні на UAT. В результаті ми завершили роботу за тиждень — проблем як таких не було, клієнт все перевірив без глюків. Самі розумієте, скільки коштів це зекономило клієнту.

Всі інші пункти дали мотивацію лідам і сеньйорам переходити на CI — робити перевірку коду, займатись тестуванням стало в рази зручніше із колосальним зменшенням проблем протягом розробки проекту.

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

Зміни в менеджменті проектів

Завдяки CI змінились такі важливі речі, як деплой і менеджмент. CI виставив вимогу ділити завдання на короткі, бо їх простіше контролювати і тестувати, а також — завдяки тому, що деплой на стейдж став однією кнопкою в Jenkins, — нові features на стейдж почали заходити руками менеджера проекту. Складності в цьому немає. Збої відтестовані на створенні білдів (там всі помилки деплоя і виявляються, бо кожен білд — це і є по суті своїй деплой), а це значить, що напряг із деплоями на стейдж знявся повністю, головне — зробити Pull Request з master гілки в staging і дочекатись білда, щоб перевірити, чи не закралась раптом помилка, яка покладе стейдж. Якщо помилки немає — merge, і лише тоді запускається аналогічний до білда деплой, але вже в папку віртуального хоста staging сайту.

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

SQL CI flow

Гадаю, багато хто зустрічався з проблемою, коли на dev базі даних все працює, а от на базі з production, де є матеріали, додані контент менеджерами, — глюки. Побороти це не так і просто, бо доводиться робити подвійне тестування.

Ми зробили хід — спробували запустити розробку на production базі даних. Кожного вечора, або по ручному запуску база даних з production стягується і використовується як початкова база для reinstall скрипта на локальному середовищі і на білдах GitHub Pull Request.

Це ускладнило систему, додало деяких нюансів в організації процесу, але на 99% виключило проблеми деплоя не production — розробники навіть локально по суті своїй постійно працюють з базою, в якій присутні останні зміни.

Звісно, це ускладнило сам reinstall скрипт, бо з’явилось багато залежностей.

І тут ми використали магію — віддали відповідальність за reinstall скрипт команді, яка працює над проектом.

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

Потрібно, щоб після імпорту бази даних в базі робились деякі зміни — будь-хто може створити Pull Request, внести ці зміни і, дочекавшись від CI сервера білда, перевірити, чи вони відбулись. Таким чином, відпала необхідність у наявності команди Operations, яка займається підтримкою і модернізацією процесу — команди краще знають, що їм потрібно.

Єдина відповідальність, з якою складно, — це інтеграція внесених змін назад в CIBox, щоб кожен наступний проект використовував всі нововведення. Ця відповідальність впала на лідів, які, в свою чергу, зацікавлені, щоб на наступному проекті все відбувалося швидше. Благо, вдалось достукатись до керівництва і виділити час на розробку самого CIBox, знову ж таки, сформувавши для них список переваг, які отримуються в результаті.

CIBox Go opensource!

Через півтора роки ми вирішили поділитись своїми наробками із спільнотою.

Наша система пройшла випробовування на Drupal6/7/8, а також на Symfony2 проектах. Може з легкістю бути адаптована для Wordpress, Laravel і будь-яких інших фреймворків. І не тільки PHP.

Ми проводили codesprint, в ході якого виявили можливості системи для великих команд і отримали докази, що система працює без збоїв в командах до 100 учасників.

В ній головне — ідея.

Ідея того, що master — завжди стабільний. Всі скрипти, які запускаються на CI сервері, — під контролем команди і можуть бути змінені в процесі розробки, щоб відповідати вимогам проекту.

Запуск нового проекту — ~1 година (Розвертання DigitalOcean Droplet і запуск jenkinsbox.yml із github.yml із налаштуванням базових доступів).

Основна мета відкриття проекту — ми шукаємо таланти. А також будемо щасливі отримати наробки спільноти в проект для розвитку даного продукту, адже він дозволяє вести розробку з великим задоволенням і зменшеними ризиками.

47 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Крутий пост. Працював майже за такою ж схемою, єдине що не юзали PHP_CodeSniffer і ще використовували Travis — travis-ci.org, він з коробки добре інтегрований з Github-ом :)

travis не може робити білди, правда?

ні не може :(, для білдів всерівно юзався jenkins, просто при розростанні проекта не так то просто запускати білди і їх тривалість перевалює за пів години.

хм... welcome2cibox — у нас білди збираються за 3-10 хвилин.

www.youtube.com/watch?v=4-Ol8kN_A0M. Ось і відео презентації. Enjoy

Это все прекрасно, но почему же не Docker?

Докер настільки чудова технологія, що аж непотрібна.
Я не написав, ми його використовували, для піднімання solr для білдів. Але відмовились. З ним було більше проблем, чим плюсів

А можливо проблема з докером не на стороні докера, а на стороні команди, яка його використовує?
Більше 40 проектів побудовано і налаштовано мною в комплексі з Bamboo, TeamCity і ніяких неочікуваних збоїв не було.

Просто використовувати вагрант, який сам по собі з’їдає левову частку ресурсів машини і швидкість віртуальних машин (запуску/роботи/зупинки) одна із найгірших.

Андрiй, гадаю, що є ця стаття англійською мовою. Поділись посиланням, будь-ласка.

Ще немає )))
В процесі.

Буде доповідь по цій статті на DrupalCon Barcelona 2015 — приїжай, послухаєш )

От і добре. Там послухаю. Але я хочу англомовним друзям дати посилання також. То ж буду слідкувати за публікаціями :-)

Буду вдома — відпишу детальніше, але поки лише одне питання: чому друпал? От ви всі такі круті, всякі слова розумні знаєте, намагаєтеся дотримуватися отого всього, а пишите на друпалі.
Ота вся ваша простиня спокійно замінюється 3-4 командами *ім’я будь-якого нормального фреймворку* + composer + gitflow + один конфіг віртуалки, яку всі юзають (люди, які використовують Mamp Pro на макі або OpenServer на вінді беруться за CI — хе, хе))

З задоволенням почитаю про ваш досвід.

Так чому все-таки друпал ви поясните? Я не вірю, що ті, хто юзають кодсніфери і дженкінси, пишуть щось на друпалі. І я зараз абсолютно серйозно.

Я не вірю, що ті, хто юзають кодсніфери і дженкінси, пишуть щось на друпалі.
Значить я і вся наша компанія не існує )))

На питання «чому друпал?»
Ну так історично склалось.
Ми і Symfony2 використовуєм і не тільки його. Інструмент тут пофіг. Будь-який фреймворк буде мати такі самі проблеми. Тут же стаття не про фреймфорки, а про те, як людей організувати в ефективні команди.

а пишите на друпалі
Вы так говорите, вроде это что-то плохое. Уверен, что ответ будет “потому что бизнесу важна скорость разработки, и с цмс она выше, чем с нуля”.
Кроме того, насколько я помню, друпал уже несколько лет написан на Симфони. Вот вам и *ім’я будь-якого нормального фреймворку* + composer.

Все правильно. В даному випадку швидкість розробки має ключове значення.
Бізнес диктує правила, а не фреймворки.

Використовує «під капотом компоненти symfony» і «написаний на symfony» — абсолютно різні речі.
Я не кажу, що Drupal — це погано. Я кажу, що в місцях, де так цінується «ентерпрайз», Drupal, як правило, ніхто не використовує і я їх цілком розумію. Але відповідь мене цілком задовольнила, часто «так склалося історично» реально важко перебороти.

що в місцях, де так цінується «ентерпрайз», Drupal, як правило, ніхто не використовує
дана стаття якраз про ентерпрайз... )))
Використовує «під капотом компоненти symfony» і «написаний на symfony» — абсолютно різні речі.
Ґаразд, яхз.
Я не кажу, що Drupal — це погано.
То вибачайте, враження було саме таке :)
в місцях, де так цінується «ентерпрайз», Drupal, як правило, ніхто не використовує
Я ще в 2008 попрацював в бодішопі, який половину проектів клепав на Друпалі. І там ще тоді ніфіґова оптимізація була; ґадаю, що зґодом Друпал мав стати тільки кращим. Серед проектів точно були усілякі казино та інтернет-крамниці. Як до мене, то достатньо ентерпрайз. Звичайно, якщо за ентерпрайз брати банки, то там процессінґ не на друпалі.

Будь-який інструмент поганий, якщо його не вміти )))

От ви всі такі круті, всякі слова розумні знаєте, намагаєтеся дотримуватися отого всього, а пишите на друпалі.
якраз те, що пишемо на друпалі і допомагає знати
всякі слова розумні

Continuous, Integration, Workflow — крутые слова. Круто звучат.

Дякую за крутий коментар )))

Continuous, Integration
Запятая лишняя.
[...] — крутые слова. Круто звучат.
Так исторически сложилось, что оно так называется. Всегда можно, конечно, подискутировать, как правильно говорить — «разработчик» или «программист», «workflow» или «рабочий процесс». Но многим пофиг на выдуманные проблемы.
Continuous, Integration
Запятая лишняя.
Не лишняя. С помощью запятой я раздробил пафосные фразы на мельчайшие атомы пафоса.
Но многим пофиг на выдуманные проблемы.
Разве «Continuous Integration» и «Workflow» не являются выдуманными проблемами?
Разве “Continuous Integration” и “Workflow” не являются выдуманными проблемами?
Так ясамо як і IDE
ми стопорились саме на стандартах, бо багато розробників не дотримувались їх, і тут майже не було залежності від рівня — лажали всі

У нас на проекте первый шаг билда в Дженкинс — проверка соответствия стандартам закомиченного кода. Т.е. разработчик обязан сделать по стандартам свой код, а наличие в проекте экскрементов мамонта билд не завалит. Если проверка на стандарты фейлится, то тесты даже не запускаются.

Все довольны.

В нашому випадку були проекти, в яких стандарти коду були другорядними, проекти SLA, де код був не наш. Обов’язковість дотримання стандартів стала адміністративною, а не технічною )

В том же jenkins есть базовые величины min количества ошибок, после которых надо делать fail, первый раз посмотрели на количество приняли за базу, стало больше — fail.

Хороший вариант, но идея проверять только diff мне нравится больше. Если отталкиваться от базового количества, то можно пофиксить часть старого кода и с чистой совестью коммитить треш до прежнего значения базового уровня. Кроме того, diff проверяется быстрее, чем полный проект.
Но это я на наш проект смотрю (питон), в других случаях всё может быть иначе.

Саме так. Перевірка diff — це те, що дозволяє почати роботу з будь-яким проектом. Старий код приймається за legacy і з всім гавнокодом пропускається від тестування. Можна частинами кидати на перевірку і фіксити, якщо для цього є місце в бюджеті.

Наразі складно передати в Jenkins кількість помилок з програми, яка запускається в shell
Тому для Jenkins — php code sniffer fail — це одна помилка.

Наблюдение, когда база под терабайт не всегда возможно ночное backup/restore для dev.
Pull request у bitbucket все таки интересней, чем на github. В bitbucket можно и добавить review-ов, можно зааппрувить, а в github знай раздавай :+1: в коментах.

Тогда нужно делать промежуточный дамп с прода и делать его sanitized.
В идеале prod -> dev environment.
В данном случае подойдет prod -> sanitize -> dev environment.

Не согласен по поводу BitBucket. На GitHub можно делать ассайн на пользователя, этого вполне достаточно. Так же на GitHub намного удобнее делать мануальное ревью кода плюс огромное кол-во других удобных фич.

По поводу аппрува, то тот человек который делает ревью он либо мерджить PR либо пишет замечания в комментариях. Таким образом после мержа он берет на себя ответственность что функционал работает правильно.

В github вы не назначите больше чем одного ревьювера, а практика с bitbucket показывает, что 2 человека более качественней делают замечания чем 1.

Ничто не мешает написать коллегам в корпоративном чате и попросить сделать ревью. Сделать ассайн это не значит получить качественное ревью.

Плагин для Jenkins для BitBucket очень сырой. На BitBucket нету статусов для PR(когда билд зафейлился, билд в процессе или билд успешный). Нужно постоянно заходить и ждать сообщение от бота(т.е. нельзя понять что происходить с PR когда ты смотришь на список PRs).

Я не выступаю с критикой, я просто показываю что есть альтернатива и да, плагин в jenkins для bitbucket сырой.

І з терабайтною базою працювати реально.
Достатньо в базі вичищати частину даних, які дублюються. Ну або якщо всі дані потрібно — тоді просто бази накидувати наперед для білдів, а на етапі збірки — просто підключати код до бази.
Практика показує — що чистка бази для створення легкого дамку — оптимально.

В мене все намного складніше, одним словом — 1с.

теж реалізовується. База ж SQL )))
Інша справа, що для 1С такої кухні важко досягнути — суть то не та... Хіба що розробка конфігурації постійна, і команда чоловік 10 — тоді це може бути корисним.

В мене досягнуто, unit-тести, bdd-тести, codecoverage, autodeploy, code-review , але з базами тяжко, на кожну гілку restore робити.

Ми так і робим. На кожен PR — sql source команда.
Для швидкості заливки — різні методи є.
В 1С — думаю вичистити історію в базі і залишити лише потрібну кількість словників — достатньо для розробки і тестування.
Хоча кожен раз її інсталювати — та ще задача. Ідея білдів повинна бути підтримана швидкістю. Із 1С — це складно.

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