Комментарии 6
Отлично! Все больше людей понимают, что автоматизация [тестирования] это не опция, а способ повышения эффективности бизнеса, жизненная необходимость, чтобы оставатья конкуррентноспособным.
В тексте описана проблема, когда скопились "релизы, которые еще рано выливать в master " и я не увидел решения. Как решили проблему? Разве концепция релизов не предусматривает планирование и реализацию только тех задач, которые должны быть в релизе?
В тексте описана проблема, когда скопились “релизы, которые еще рано выливать в master ” и я не увидел решения. Как решили проблему?
Раньше была была ветка dev и под нее была одна площадка, туда сливались все задачи.Теперь под каждую задачу, создается отдельная площадка, т.е. получается, что площадка это master + код по задаче/релизу.
Разве концепция релизов не предусматривает планирование и реализацию только тех задач, которые должны быть в релизе?
Тут другая система. Условно есть несколько видов релизов/задач и несколько команд. Например, есть текущие задачи/исправления. А есть крупные релизы(например, интеграция с поставщиком), которые тоже должны быть на площадке(потому что сам поставщик их тестирует)
Раньше была была ветка dev и под нее была одна площадка, туда сливались все задачи.Теперь под каждую задачу, создается отдельная площадка, т.е. получается, что площадка это master + код по задаче/релизу.
Если я правильно, понимаю, то конфликтов при объединении при таком подходе не избежать. Ведь master уже изменился на предыдущем релизе и текущая сделанная задача, может не работать или работать не так как надо.
Не сообщили самого интересного: сколько стоила разработка/поддержка ДО рефакторинга, сколько стоит теперь. Точных цифр, конечно же, не жду, но хотя бы порядок узнать было бы очень интересно. Какого уровня проект должен быть, чтобы позволить себе "9 разработчиков на проекте"?
Тестовый контур как спасение при частых релизах