як залишатися ефективними, коли збірка майже завжди порушена

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

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

Сказавши, що протягом дня у кожного є кілька 10-15 хвилин вікон, де ми дозволяли заїхати.

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

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

Для початку цей коментар:

... наявність філії передбачає додаткову складність і, таким чином, додаткову роботу ...

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

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

Коли вони нарешті натискають, це фактично злиття .

Той факт, що ваші гілки та злиття неявні, не усуває зайву складність, яку ви хвилюєте, це просто приховує. Правда полягає в тому, що виразність цього процесу може допомогти вам (множина = вся команда) навчитися керувати ним.

Тепер, кажете ви

нікому заборонено заїзд, поки будівництво червоне

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

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

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

Загалом відповідь на

як залишатися ефективними, коли збірка майже завжди порушена

є: припиніть ламати збірку .

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

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

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

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

• ^{Бічна примітка, кожен раз, коли менеджер робить або каже щось, що змушує вас уникати зобов’язань, зберігати код на локальному рівні, переводити їх слова жирним і простим "Я некомпетентний" .}

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

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

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

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

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

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

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

Я думаю, що доки ти вважаєш, що ти "просто розробник", і тому ти не можеш змінити те, що ти будеш страждати від цієї проблеми.

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

Вам потрібно зробити все можливе, щоб краще змінити процес і скоріше сказати, що ви шкодуєте пізніше, а не просити дозволу.

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

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

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

Проста зміна системи CI зробить це: будь-яка зміна, яка порушує збірку, автоматично відкочується. Ще краще, нехай сховище CI стане місцем розміщення, де зміни переходять у авторитетний сховище лише тоді, коли збірка зелена. Тут можуть допомогти такі інструменти, як Герріт.

Тут можуть допомогти ще дві речі:

• чи може ваша команда провести тест на куріння ІП на місцях? Якщо ви переконайтеся, що ви не порушили збірку - або принаймні не зламаєте збірку звичайними способами без необхідності виконувати і запускати управління та команду ire.
• Є багато способів визначення зламаних збірок залежно від того, як ви архітектор CI. Це включає визначення зламаного - в умовах важкої розробки ми не вважаємо невдалі тести перервою, а скоріше іншою метою, спрямовані на досягнення.

Але вам слід справді дивитися на гілки.