Если работает один человек, то можно и на билд сервер загружать. Правда тесты, наверняка, тесты компоненты, а не тесты приема. А вот если 200 человек работает, то билд будет падать раз за разом. Это и есть эффект турбулентности, когда проводная способность билда меньше, чем поток изменений проходящий через него.
Вот статистика с настоящего, не самого перегруженного сервера:
120 модулей в проекте
450 разработчиков
приблизительно 100 изменений в день (как вы видите еще не все работают с одной веткой)
12 билдов в день
в среднем, каждый билд длится 30 минут
в среднем, каждый билд строит 8 новых изменений
обычно 2 билда успешные, первый и последний (в конце дня все работают над стабильностью)
Сегодня, основная сложность — построить среду быстро (меньше минуты) и создать набор правильных тестов, которые проверяют работу бизнес процессов в целом, в дополнение к тестированию отдельных компонент.
Проверка на билд сервере это первый этап так называемого «сдвига влево», т.е. подальше от prod. На сложных проектах этого тоже не достаточно.
На каждую ветку, с которой работает программист есть как минимум одно изменение. Желательно каждое изменение проверить перед выкладыванием кода в ветку и лучше, конечно, с как можно большим разнообразием тестовых данных. Полагаю, это не только мое мнение. Единственное препятствие для такого подхода — время и усилия, затраченные на поднятие сред, закачку тестовых данных и запуск тестов. Это как раз та область, которая будет развиваться в следующие 5-10 лет под “зонтиком” Agile.
Дополнительно к инструментам типа Docker, Cucumber & Service Virtualization будут появляться новые, цель которых будет ускорить, упростить и удешевить подъем сред, закачку данных и запуск тестов приема.
Именно так!
Как повысить качество? Это и есть следующий этап развития Agile
Правильно построенные тесты в Cucumber позволяют однозначно определить соответствие критериям приема. Ну а последнее позволяет запустить сложную систему до того как все куски кода написаны. Например, в приложении для покупки книг, правило написанный тест позволит проверить, насколько система отвечает требованиям, если книга не найдена а виртуализация сервисных приложений сократит время до проверок и демонстрации — можно будет запускать приложение до того, как база данных готова.
Это точно! С толковыми ПО и без аджайла всё отлично работает :-)
Один из способов — дать попользоваться результатом на ранних этапах, задолго до того, как он окончательно готов. Опять же все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
Именно так, качество связано с определением критериев сдачи, в данном случае проектированием на начальном этапе или обработкой CR.
Самая распространенная модель работы с CR — через backlog. Недостаток заключается в возможном несоответствии критериев сдачи с имплементацией ТЗ. Этот недостаток должен быть устранен за счет показа результата заказчику. Это не сложно для простых проектов. Однако для более сложных вопрос среды и тестов приема критичен. В идеале все тесты приема работают и заказчик доволен работой после ручных проверок. Это работает, когда CR не очень много или они могут быть проверены одновременно. На деле все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
Это то, что происходит обычно:
dev
stage
prod
несколько сред для тестеров, а у разработчиков только одна, да и та хромает.
Это я говорю про то, как работает сегодня.
А вот представьте себе вариант, когда Вы открываете eclipse или другой IDE, и, нажимая на кнопку, получаете новую среду. Ваш новый код туда закачан, есть все данные для тестов, которые QA, Ops и анналисты согласовали и подготовили, более того, даже acceptance тест можете запускать нажатием кнопки и можно подключаться с дебагером.
В таком случае в течении дня у Вас будет как минимум одна “локальная” среда для каждого набора тестовых данных или может даже для каждого теста. Такая имплементация на уровне виртуализации слишком дорогая, а вот контейнеры более подходят для этого.
Спасибо за очень хороший вопрос! Естественно, однако я не видел что бы DSDM действительно работал на практике, тем более на больших проектах — он слишком общий. В жизни все значительно сложнее. Например, один из принципов — согласие о критерии сдачи проекта до начала разработки. На практике бизнес не согласится принять что-то, до того как видел как оно работает в деле.
Риск во многом зависит от качества, если убрать конечно элемент везения! Я с вами согласен, качество это способ уменьшения риска. А инструменты для предсказания степени удовлетворения — https://cucumber.io и https://www-01.ibm.com/software/rational/servicevirtualization/
Парадокс именно в том что в первом десятке находятся корпорации, для которых изменение может обойтись слишком дорого. Пионерами Agile были компании, которые не были включены в лидеры рынка.
Как минимум 1 к 1, и даже иногда, на каждую ветку необходимо 3-4 среды: поверхностные проверки, разные вариации данных, разные вариации поддерживающих сервисных приложений и т.д. Допустим ТЗ добавить оплату картой покупки книги. Необходимо проверить новый код на стабильность, безопасность и функциональность. Таким образом уже три среды на одно ТЗ, каждая со своими инструментами, заточенными на тип проверки.
Действительно, 15 лет назад Agile был набором принципов, однако сегодня он объединяет многие дисциплины производства. Даже такие компании как Zara и Ikea работают по Agile, и речь не идет об их отделе разработки ПО. Прошу прощения за ссылку на английском: http://www.forbes.com/sites/stevedenning/2016/08/13/what-is-agile/#2d5433b4b926
Спасибо! Я рад что вы мой постоянный читатель! Речь действительно о «зонтике» Agile, который развернулся намного шире и покрывает не только отделы разработок, а уже всей компании. Проблема именно в том, что результат действительно зависит от того как внедряют Agile. Необходимо новое дополнение к «зонтику», которое будет сопровождать внедрение Agile, и позволит четко определить, что сделано не по правилам и как это исправить. Именно этим и занимаются сегодня разработчики Agile.
Количество параллельных веток кода, с которыми одновременно работает один разработчик: починка багов, нынешняя версия, новая версия, версия для определенного заказчика, экспериментальная версия и т.д.
Это к сожалению происходит сплошь и рядом. Как вы и говорите — «так устроена психология человека». По Agile никто из «куриц» не должен контролировать технические решения: если тесты прошли — значит работает.
Статья именно об этом. Agile уже давно перерос из набора принципов для команд разработчиков в собирательное понятие:… Тогда же, в середине первого десятилетия 2000-х, понятие Agile было расширено и стало собирательным, в отличие от первоначального значения, ориентированного только на первый этап разработки.…
Вот статистика с настоящего, не самого перегруженного сервера:
120 модулей в проекте
450 разработчиков
приблизительно 100 изменений в день (как вы видите еще не все работают с одной веткой)
12 билдов в день
в среднем, каждый билд длится 30 минут
в среднем, каждый билд строит 8 новых изменений
обычно 2 билда успешные, первый и последний (в конце дня все работают над стабильностью)
Сегодня, основная сложность — построить среду быстро (меньше минуты) и создать набор правильных тестов, которые проверяют работу бизнес процессов в целом, в дополнение к тестированию отдельных компонент.
Проверка на билд сервере это первый этап так называемого «сдвига влево», т.е. подальше от prod. На сложных проектах этого тоже не достаточно.
Дополнительно к инструментам типа Docker, Cucumber & Service Virtualization будут появляться новые, цель которых будет ускорить, упростить и удешевить подъем сред, закачку данных и запуск тестов приема.
Как повысить качество? Это и есть следующий этап развития Agile
Правильно построенные тесты в Cucumber позволяют однозначно определить соответствие критериям приема. Ну а последнее позволяет запустить сложную систему до того как все куски кода написаны. Например, в приложении для покупки книг, правило написанный тест позволит проверить, насколько система отвечает требованиям, если книга не найдена а виртуализация сервисных приложений сократит время до проверок и демонстрации — можно будет запускать приложение до того, как база данных готова.
Один из способов — дать попользоваться результатом на ранних этапах, задолго до того, как он окончательно готов. Опять же все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
Самая распространенная модель работы с CR — через backlog. Недостаток заключается в возможном несоответствии критериев сдачи с имплементацией ТЗ. Этот недостаток должен быть устранен за счет показа результата заказчику. Это не сложно для простых проектов. Однако для более сложных вопрос среды и тестов приема критичен. В идеале все тесты приема работают и заказчик доволен работой после ручных проверок. Это работает, когда CR не очень много или они могут быть проверены одновременно. На деле все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
dev
stage
prod
несколько сред для тестеров, а у разработчиков только одна, да и та хромает.
Это я говорю про то, как работает сегодня.
А вот представьте себе вариант, когда Вы открываете eclipse или другой IDE, и, нажимая на кнопку, получаете новую среду. Ваш новый код туда закачан, есть все данные для тестов, которые QA, Ops и анналисты согласовали и подготовили, более того, даже acceptance тест можете запускать нажатием кнопки и можно подключаться с дебагером.
В таком случае в течении дня у Вас будет как минимум одна “локальная” среда для каждого набора тестовых данных или может даже для каждого теста. Такая имплементация на уровне виртуализации слишком дорогая, а вот контейнеры более подходят для этого.