Хороший робочий процес для розробки програмного забезпечення з scrum та постійною інтеграцією

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

Я думаю щось подібне:

Це був би приємний робочий процес?

Ви десь там, але я трохи розширюю вашу діаграму:

В основному (якщо ваш контроль версій дозволить це, тобто якщо ви перебуваєте на hg / git), ви хочете, щоб у кожної пари розробників / розробників була своя "персональна" гілка, яка містить одну історію користувача, над якою вони працюють. Коли вони завершують функцію, їх потрібно просунути до центральної гілки, гілки «Випустити». У цей момент ви хочете, щоб розробник отримав нову гілку, для наступного, над чим вони повинні працювати. Оригінальну галузь функції слід залишити такою, якою є, тому будь-які зміни, які потрібно внести до неї, можна вносити ізольовано (це не завжди можливо, але це хороша відправна точка). Перед тим, як розробник повернеться до роботи над старою гілкою функцій, вам слід перетягнути останню гілку випуску, щоб уникнути дивних проблем злиття.

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

У цей момент ви захочете запустити збірку та отримати артефакт життєздатної збірки з сервера CI (тобто щось, що ви могли б розгорнути). Цей крок можна пропустити, якщо ви використовуєте динамічну мову! Після того, як ви побудуєте, ви захочете запустити свої тести для одиниць, оскільки вони є основою всіх автоматизованих тестів у системі; вони, швидше за все, будуть швидкими (що добре, оскільки вся суть CI полягає в тому, щоб скоротити цикл зворотного зв'язку між розробкою та тестуванням), і їм навряд чи знадобиться розгортання. Якщо вони пройдуть, вам потрібно буде автоматично розгорнути свою програму на тестовому сервері (якщо можливо) та запустити будь-які наявні тести інтеграції. Тести інтеграції можуть бути автоматизованими тестами інтерфейсу, тестами BDD або стандартними тестами інтеграції, використовуючи блок тестування Unit (тобто "одиниця"

До цього моменту у вас повинно бути досить вичерпна вказівка ​​на те, чи є збірка життєздатною. Останній крок, який я зазвичай налаштовую з гілкою "Випуск", полягає в тому, щоб він автоматично розгортав кандидата на випуск на тестовий сервер, щоб ваш відділ QA міг робити ручні тести на дим (це часто робиться щоночі замість перевірки, щоб щоб уникнути псування тестового циклу). Це просто дає швидку інформацію про те, чи справді збірка підходить для випуску в реальному часі, оскільки досить просто пропустити речі, якщо ваш тестовий пакет не є всеосяжним, і навіть при 100% тестовому покритті легко пропустити щось, що ви можете 't (не повинен) перевіряти автоматично (наприклад, неправильно вирівняне зображення або орфографічна помилка).

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

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

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

Концептуально так. Діаграма не захоплює багато важливих моментів, хоча:

1. одиничне тестування
2. додаткові коміти
3. інсценізація часто розгортається, виробництво зазвичай не відбувається.

Ви можете намалювати більш широку систему для діаграми. Я хотів би додати наступні елементи:

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

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

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

Чи є команда тестування? Коли вони беруть участь або повідомляються? Чи проводяться автоматизовані тестування на СНД? Як поломки подаються назад у систему?

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

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

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

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

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

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

(Це легше налаштувати за Svn, ніж Hg).

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

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

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

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

Залежно від ваших ресурсів / мережі, ви можете розглянути можливість додавання різних кінцевих серверів. У нас є збірка CI, яка викликається зобов’язанням репо і припускаючи, що будує і проходить усі його тести, потім він розгортається на сервер розробки, щоб розробники могли переконатися, що він грає чудово (ви можете сюди включити селен або інші тести на UI? ). Не кожна фіксація - це стабільна збірка, тому, щоб запустити збірку на інстальованому сервері, ми маємо помітити ревізію (ми використовуємо mercurial), яку ми хочемо створити та розгорнути, знову ж таки це все автоматизовано та спрацьовує просто шляхом зв'язання з конкретним тег. Переходити до виробництва - це ручний процес; ви можете залишити це так просто, як примусити трюк збірки - це знати, яку редакцію / збірку ви хочете використовувати, але якщо ви мали належним чином позначити версію, сервер CI може перевірити правильну версію і зробити все необхідне. Ви можете використовувати MS Deploy, щоб синхронізувати зміни на виробничому сервері (серверах), або упакувати їх і поставити поштовий індекс, куди готовий адміністратор для розгортання вручну ... це залежить від того, наскільки вам зручно.

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

CruiseControl.Net використовує xml для налаштування збірок, TeamCity використовує майстрів, якщо ви прагнете уникати спеціалістів у вашій команді, тоді складність конфігурацій xml може мати на увазі щось інше.

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

Як я розумію, Scrum та інші Agile методи мають дві основні цілі:

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

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

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

Як ви, напевно, можете сказати - я також шанувальник тестових розробок. :-)

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

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

Отже, підсумовуючи:

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

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