Коли мій колега думає, що немає необхідності в тесті на своєму ПК, він вносить зміни, виконує обов'язки, а потім натискає. Потім він тестує на виробничому сервері і розуміє, що допустив помилку. Це трапляється раз на тиждень. Тепер я бачу, що він зробив 3 коміти і натискає з розгортанням на виробничий сервер протягом 5 хвилин.

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

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

Перш ніж я почав, компанія розгортала антикварні методи, такі як FTP, і не було контролю за версіями.

Я змусив їх / нас використовувати Git, Bitbucket, Dploy.io та HipChat. Розгортання не є автоматичним, хтось повинен увійти в dply.io і натиснути кнопку розгортання.

Тепер, як змусити їх не тестувати на виробничому сервері? Щось на зразок бота HipChat може відчути, що в одному рядку є повторні редагування та надсилається повідомлення програмісту.

Вам потрібен належний процес забезпечення якості (QA).

У професійній команді з розробки програмного забезпечення ви не просуваєтеся від права розвитку до виробництва. У вас є щонайменше три окремі середовища: розробка, постановка та виробництво.

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

Коли ви не можете переконати менеджмент найняти когось, щоб зробити ваш QA, то, можливо, один з вас може зіграти цю роль для іншого. Я ніколи не працював з diploy.io, але деякі системи автоматизації побудови можуть бути налаштовані таким чином, що користувач може розгортати як від розробки до стадії, так і від постановки до виробництва, але не робити обох для тієї ж збірки, тому друга людина завжди потрібно (але переконайтеся, що у вас є резервні люди на час, коли хтось із вас відсутній).

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

Ви, ймовірно, захочете отримати сервер розробників, а також бажано, також для інсценування. Ніхто ніколи не повинен просуватися від місцевого виробництва до виробництва, крім власного особистого веб-сайту. Ваш процес розгортання повинен підтримувати лише dev-> staging-> prod. Ви, мабуть, хочете, щоб хтось відповідав за підписання нових випусків - залежно від організації, це може бути керівник проекту, спеціальний контроль якості чи обов'язок, який обертається щотижня (з відчутним нагадуванням, наприклад, лише людина з пухнастою іграшкою, що потрапляє на тиждень поштовх). Однак спочатку обговоріть це зі своєю командою, щоб отримати бай-ін (див. Нижче).

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

Ви можете мати тестовий набір (у вас є один із таких, правда?), Включити чек, який визначає, чи ви перебуваєте на виробничому сервері, і, якщо він є, надсилає всім в офіс повідомлення електронною поштою Looks like $username is testing on prod, watch out. Можливо, публічно ганьбити колегу було б неприємно. Або ви можете створити технічні обмеження, такі як заборона IP-адреси вашій команді дивитися на prod (який ви можете зняти, але ви повинні виправдати).

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

Напевно, те, що ви насправді хочете, - це не за те, щоб ця поведінка була покарана, а щоб вона припинилася ?

Я змусив їх / нас використовувати [...]

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

Тож почніть з розмови.

Дізнайтеся, чому це відбувається (чи машина вашого колеги не настільки хороша для тестування? Ваш колега не впевнений у своїх галузях функцій чи застряг у мислячому режимі svn, коли фіксація та натискання однакові?), Поясніть, чому для вас проблема, що не перевірений код іде в програмі dev / staging / prod, і подивіться, чи можете ви зробити щось, щоб змінити, чому це відбувається (ваш колега швидше зробить те, що ви хочете, якщо ви тільки що зробили приємніше тестувати на місцевому рівні, ніж якщо ви щойно їх побили).

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

На роботі ми уникаємо цього, використовуючи Герріт . Gerrit - це система огляду коду, яка виступає воротом до вашої основної / виробничої гілки Git, яку умовно називають "майстер". Ви маєте відгуки про код, правда? Здається, ви особисто ви робите їх виключно. З Джеррітом ви переходите до певної інсценізації, яка після того, як ви та ваш колега виконали процес перегляду коду задовільно, потім Герріт з'єднується з вашим головним відділенням. Ви навіть можете підключити Герріта до сервера CI, щоб виконати тестові одиниці, перш ніж хтось отримає електронний лист для перегляду змін. Якщо у вас немає сервера, на якому можна встановити інструмент CI, Codeship має хороший безкоштовний план, який можна використовувати як доказ концепції.

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

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

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

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

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

Ось де структуровані зустрічі, як-от "уроки, засвоєні" після великих інцидентів у виробництві, можуть бути дуже корисними. Спробуйте змусити всіх погодитися, включаючи відповідного розробника, про те, що огляд коду, тестування блоку, комплексне тестування тощо потрібно проводити кожен раз (і ви можете почати впроваджувати ідею постановочного середовища і тут). Це не повинно бути важким, і це дуже розумно. Потім попросіть команду разом придумати якісь міцні правила щодо того, як це робити. Чим більше сприяє розробник, який викликає проблему, тим більше вони будуть відчувати, як дотримуються правил, і починають розбиратися, чому в їх поведінці була проблема.

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

Це не рідкість , особливо в невеликих командах. Не робіть для цього великої справи, але неформальне правило:

Розбити збірку, принести пончики.

Або 1) Ви будете отримувати пончики двічі на тиждень або 2) вони будуть дотримуватися стандарту.

Піднесіть це на зустрічі. Не звинувачуючи, не згадуйте нікого по імені, але щось подібне до цього: "З моменту запровадження стандартів контролю та розгортання версій все стало набагато простіше, і сервер займає більше часу, ніж раніше. Це чудово! Однак все ще спокушати скористатися ярликом і подати без належного тестування. Хоча це азартна гра, і наш сервер знаходиться на лінії. Я пропоную, щоб відтепер хтось із нас подав код, який порушує сервер, відповідальна особа приводить пончики для команди наступного дня ».

Замініть щось інше на пончики за бажанням, і не робіть його дорогим - обід для всієї команди був би занадто великим, але коробка пончиків на суму 5 доларів або лоток з фруктами / овочами, чипси та окунки тощо, ймовірно, буде дратувати достатньо, щоб вони насправді зважили ризик на зручність пропуску тестування, не роблячи його тягарем, який би відштовхував їх від команди чи компанії.

Тепер, як я можу їх змусити ...

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

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

Чому це болить вам проблеми на живому сервері, а не для цього хлопця? Ви знаєте щось, чого він не робить? Що ви можете зробити, щоб він бачив речі так, як ви?

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

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

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

Скажімо, у вас є помилка, де ви використовуєте ідентифікатор запису, і помилково сума рахунку в центах зберігається в змінній, яка використовується для ідентифікатора запису. Тож якщо я заплачу 12,34 долара, тоді запис з id 1234 буде змінено. Чи можете ви відновитися після цього, якщо програмне забезпечення працює протягом декількох годин, поки помилка не буде виявлена? (Якщо і правильний запис, і запис 1234 оновлюються, ви виявите це лише тоді, коли буде використано запис 1234, тому це може залишатися непоміченим досить довгий час).

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

Ви чітко розумієте різні можливі технологічні та технологічні рішення. Питання в тому, як керувати колегою.

Це по суті управління змінами.

По-перше, я б сказав тихе слово з засновником, щоб переконатися, що він / вона на борту з вашої точки зору. Якщо буде відмова від виробництва, я би сподівався, що засновник буде дуже стурбований цим питанням та бажанням змінитись.

По-друге, ви працюєте в невеликій команді, і, ймовірно, варто спробувати залучити всю команду до вдосконалення процесів.

Налаштування регулярних ретроспектив (наприклад, щотижня). Майте всю команду:

• Визначте проблеми
• Ідеї ​​волонтерів щодо вдосконалення трудової практики
• Залучіться до впровадження цих практик

Звичайно, слід випливати, що тоді вся команда також допомагає забезпечити дотримання вдосконаленої практики.

Я думаю, ви виявили пару проблем:

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

Чесно кажучи, я вважаю, що налаштування просто божевільне. Як мінімум людей, які можуть вручну викликати поштовх до виробництва, слід обмежувати лише набором людей, яким можна повністю довірити ретельний перегляд та перевірку всіх вихідних змін (незалежно від того, хто є автором змін) перед тим, як викликати натиск. Надання будь-кому дозволу перевірити код коду, щоб також довільно викликати поштовх до виробництва, це просто просить неприємностей. Не лише від недбайливих та / або некомпетентних розробників, але й від недоброзичливих або злісних сторонніх, які трапляються на компрометацію одного з ваших облікових записів.

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

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

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

2. Здається, ви, можливо, не встановили чітко визначених стандартів / принципів розвитку.

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

Спробуйте створити культуру, яка чітко повідомляє, що очікується від розробників, а також стандарти та рівень якості, який вони мають підтримувати. Налаштування визначення зробленого, що включає принаймні ручне тестування (або, переважно, автоматизовані тестові корпуси, які можна запустити в рамках процесу збирання / розгортання) допоможе в цьому. Як це може мати наслідки для зламу конструкції. Або більш важкі наслідки для порушення системи виробництва. Зауважте, що ці дві речі дійсно повинні бути незалежними, і не можна одночасно порушувати і збірку, і виробничу систему (бо зламані збірки ніколи не повинні бути розгорнуті).

Вам слід інтегрувати в компанію процес постійної інтеграції + рецензування. Bitbucket дозволяє легко.

І +1 на сервер розробників, запропонований іншими користувачами.

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