Подход Agile можно анализировать сразу с двух позиций: как особую инструкцию к определенным действиям и как процедуру поиска багов.

Опытные разработчики и тестировщики со временем находят те подходы, которые помогают достигать им максимальной продуктивности.

Дополнительно, подобные методики обнаруживают критерии, пагубно влияющие на продуктивность, усугубляя этим проблемы, к которым они, так или иначе, приводят.

Процесс непрерывной поставки ПО — это одновременно рецепт реализации методики Agile, а также явный способ нахождения неэффективных процессов.

[highlight dark=”no”]Кроме того, дабы полноценно использовать все положительные стороны Agile, необходимо неуклонно следовать ее принципам на каждом из этапов создания и тестирования ПО.[/highlight]

Мало полезного в регулярных планах, если пользоветельские истории и исправление багов накапливаются в репозиториях, перед тем как попасть к ответственным лицам и клиентам.

Почему непрерывное развертывание ПО это постоянный стресс-фактор и как с этим бороться?

Есть в практике многих продуктовых компаний такое состояние разработки программного обеспечения, которое можно именовать как «непрерывное нервное напряжение».

Это своего рода итог отсутствия любых попыток внедрения непрерывной интеграции или непрерывной поставки системных компонентов.

Подобные вещи, как правило, сопровождаются тем, что:

• Коммиты правок выполняются в базовую ветку, так как есть опасение того, что у кого-то может возникнуть недовольство;
• Базовая ветка программного кода находится в нестабильном состоянии;
• Ошибки и дефекты ПО скрыты в мешанине регулярного редактирования кода, когда требуется очень много времени, дабы найти те или иные изменения в системе;
• Когда QA-инженеры приступают к тестированию ПО, им приходится обращаться к отделу разработки, чтобы выявить текущий статус и рабочую сборку ПО;

Если подобные вещи вам хоть раз, но встречались в повседневной практике, помните — выход есть!

Поразмышляйте о том, как методология «тестирование и адаптация» повлияли на качество вашего процесса планирования проверки ПО, а далее попробуйте распространить его на процессы создания и выпуска веб-продуктов.

Вообразите, что конкретно можно выявить с позиции проблем в каждом исполненном коммите.

[highlight dark=”no”]А теперь представьте, что продуктовые команды могут находить баги в локальном окружении даже до того момента, как будет сделан коммит.[/highlight]

То, что мы сейчас проанализировали — это базовые причины, которые требуют для методологии Agile непрерывной поставки: программистам, так или иначе, потребуется обратная связь.

Самое удивительно то, что первый (и самый важный) шаг к непрерывному выпуску ПО могут делать даже тестировщики.

Необязательно рекламировать на каждому углу вышеописанный метод или убеждать ваш отдел, что Etsy — именно то, к чему стоит всем стремится.

И в мире пока еще не придумали настолько оригинальных технологий, к которым невозможно было бы применить методики и базис непрерывной поставки ПО.

Попробуйте донести всей вашей организации по контролю качества, что непрерывная поставка — это круто, и от неё есть существенный прок и тогда ваши процессы разработки и тестирования разнопланового программного обеспечения станут максимально эффективными и понятными.