Як ви підтримуєте код розробки та виробничий код? [зачинено]

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

Як ви, хлопці, підтримуєте свій код розробки та виробничий код?

Редагувати - додаткове запитання - чи дотримується ваша команда розробників протокол "виконувати як скоро, як можна, і часто навіть навіть, якщо-код-містить-мінор-помилки-або-є-незавершений" або "виконувати- ТІЛЬКИ протокол ідеального коду "під час здійснення коду до відділення" РОЗВИТКУ "?

Оновлення 2019 року:

У наші дні питання буде розглядатися в контексті використання Git, і 10 років використання розподіленого робочого процесу розвитку (співпрацюючи переважно через GitHub ) показує загальні найкращі практики:

• masterце галузь, готова до розгортання у виробництво в будь-який момент: наступний випуск із вибраним набором гілок функцій, об'єднаних у master.
• dev(або гілка інтеграції, або ' next') - це те, де гілка функції, обрана для наступного випуску, тестується разом
• maintenance(або hot-fix) гілка - це поточне виправлення випуску / виправлення помилок, з можливими злиттями назад до devта абоmaster

Такий робочий процес (де ви не зливаються devз master, але де ви зливаєте тільки функцію гілка dev, а потім , якщо обраний, щоб для masterтого, щоб мати можливість легко впустити мають філії не готові до наступного випуску) реалізується в Git repo себе, з gitworkflow (одне слово, проілюстроване тут ).
Дивіться більше на rocketraman/gitworkflow. Історія створення цього процесу на основі магістральних шляхів відзначається в коментарях та обговореннях цієї статті Адама Димітрука .

^{(Джерело: Gitworkflow : Підручник, орієнтований на завдання )}

Примітка. У цьому розподіленому робочому процесі ви можете виконувати будь-коли, коли вам захочеться, і без проблем надіслати на особисту гілку деякі WIP (незавершене виконання робіт): ви зможете реорганізувати (git rebase) свої зобов’язання, перш ніж зробити їх частиною гілки функцій.

Оригінальна відповідь (жовтень 2008 р., 10+ років тому)

Все залежить від послідовного характеру управління випуском

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

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

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

Що стосується виробничого коду, вам також потрібно керувати своїми гілками патчів , пам’ятаючи, що:

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

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

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

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

Щоб відповісти на коментар Віль М.:

• майте на увазі, що відділення dev не означає «одну гілку на розробника» (що спричинить «злиття божевілля», оскільки кожен розробник повинен був би злити роботу інших, щоб побачити / отримати свою роботу), а одну гілку розробників на розробку зусилля.
• Коли ці зусилля потрібно об'єднати назад у магістраль (або будь-яку іншу "головну" або випускну гілку, яку ви визначаєте), це робота розробника, а не - повторюю, НЕ - менеджера SC (який би не знав, як вирішити будь-яке конфліктне злиття). Керівник проекту може контролювати злиття, тобто переконайтесь, що він починається / закінчується вчасно.
• кого б ви не вибрали для злиття, найважливішим є:
  • мати тестові одиниці та / або середовище складання, в яких можна розгорнути / протестувати результат злиття.
  • визначити тег до початку злиття, щоб мати можливість повернутися до попереднього стану, якщо злиття виявиться занадто складним або досить довгим для вирішення.

Ми використовуємо:

• виключно галузь розвитку

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

• випуск гілки

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

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

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

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

На початку запиту на реєстрацію:

Якщо вам потрібно тільки ИДЕАЛЬНОЕ CODE має перевірятися, то на самому ділі нічого не треба перевіритися. Немає код здійснений, і для контролю якості для перевірки та тестування, він повинен бути в галузі розробки так що новий виконуваний файл може бути побудований.

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

Раз у раз неминуча комбінована перевірка коду та даних зробить програму непридатною до моменту створення нового коду. Щонайменше, що ми робимо - це додати "ЗАЧЕКАЙТЕ НА БУДІВЕЛЬ" у коментарі до реєстрації та / або надіслати електронний лист.

Для чого це варто, так ми це робимо.

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

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

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

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

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

Чому ніхто досі про це не згадує? Вдала модель розгалуження Git .

Це для мене кінцева модель розгалуження!

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

Код розробки на гілках, Живий код, позначений на Trunk

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

Ось більш детальне покрокове пояснення:

1. Робіть усі розробки на гілці, регулярно виконуючи свої обов'язки.
2. Незалежний код Перегляд змін після завершення всієї розробки.
3. Потім передайте гілку на Тестування.
4. Після завершення тестування філій, об'єднайте код у відділення Release Candidate.
5. Випуск Кандидатська гілка регресії перевіряється після кожного окремого злиття.
6. Підсумкове тестування якості та контролю якості проведено на RC після того, як усі гілки розробників об'єдналися.
7. Як тільки QA та UAT будуть прийняті, об'єднайте випускний відділення у гілку MAIN / TRUNK.
8. Нарешті, позначте Trunk у цьому пункті та розгорніть цей тег у прямому ефірі.

dev йде в магістраль (SVN стиль) і релізи (виробничий код) отримують власні гілки

Це "Модель відгалуження за призначенням" (рис. 3 у Важливості моделей розгалуження /! \ Pdf)

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

Жоден код не допускається до виробничого коду до того, як він був ретельно перевірений (контролерами якості та кодами).

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

О так - ще одне - ми зберігаємо невиробничий код (тобто такий, який НІКОЛИ не буде випущений - наприклад, сценарії інструментів, тестування утиліт) у резюме HEAD. Зазвичай його потрібно чітко позначити, щоб ніхто його «випадково» не відпускав.

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

Для стовбура єдиним правилом є те, що команда не повинна нічого порушувати. Для управління wip-кодом та неперевіреним кодом ми просто додаємо відповідні, якщо статисти, щоб полегшити вмикання та вимкнення.

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

Я використовую git і маю 2 гілки: master та maint

• master - код розробки
• maint - виробничий код

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

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

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

Розробники проекту впроваджують зміни у власну галузь свого проекту. Періодично випуск об'єднується назад у галузь розвитку.

Після того, як робочі пакети на гілці будуть усі QA'd (тест одиниць, тест системи, огляд коду, огляд QA тощо), гілка об'єднується у гілку випуску. Нові збірки будуються з гілки випуску, і остаточне підтвердження відбувається на цій версії.

Процес в основному нормальний, доки проблема не буде виявлена ​​після злиття. Якщо WP "застряє" після його об'єднання, він затримує все після нього, поки він не буде виправлений (ми не можемо зробити ще один випуск, поки не випущений застряглий).

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

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

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