Я являюсь частью группы разработчиков с 5 командами, всего около 40 разработчиков. Мы следуем методологии Scrum с 3-недельными спринтами. У нас есть установка непрерывной интеграции (Jenkins), конвейер сборки которой занимает несколько часов (из-за обширных автоматических тестов). В основном процесс разработки работает хорошо.
Однако мы наблюдаем, что после нескольких дней нового спринта наша сборка часто становится нестабильной и остается шаткой до тех пор, пока конец спринта не завершится. Отрицательный эффект этого состоит в том, что шаги сборки далеко вниз по конвейеру, особенно UI- / Webtests, не выполняются в течение нескольких дней (потому что запускаются только при «зеленой» сборке). Следовательно, вновь появившиеся ошибки часто обнаруживаются только очень поздно в спринте.
- Каждый коммит проверяется на соответствие базовому набору тестов. После проверки изменение передается мастеру после проверки кода (Gerrit).
- Базовые юнит-тесты запускаются каждые 30 минут, продолжительность менее 10 минут
- Интеграционные тесты запускаются каждые 2 часа, продолжительность 1 час
- UI- / Webtests запускаются на успешных интеграционных тестах, продолжительность нескольких часов
В зависимости от того, кто отвечает за стабильность сборки во время спринта (эта ответственность передается за спринт), могут существовать промежуточные, специальные «фиксации остановки», чтобы вернуть сборку в стабильное состояние.
Итак, мы хотим:
- Наши команды разработчиков разрабатывают и фиксируют изменения во время спринта без помех
- Наш процесс сборки следует прекратить в случае неудачи на этапе сборки, поскольку последующие результаты сборки не имеют большого значения
- Наш процесс сборки, чтобы предоставить разработчикам качественную обратную связь на своевременной основе
Учитывая (2), точки (1) и (3) кажутся противоречащими друг другу. У кого-нибудь есть хорошая практика, как с этим бороться?
( В настоящее время мы ослабляем точку (2) и разрешаем продолжение сборки даже на неудачных этапах сборки. У меня пока нет отзывов о том, как это влияет на наше качество )
Спасибо симон
источник
several hoursто это реальная проблема. это означает, что комбинированное решение слишком большое и слишком широкое. Вы должны попытаться создать компонентное решение и затем иметь небольшие куски кода в виде пакетов (так или иначе доступных на всех основных языках на всех платформах). Таким образом, любые изменения будут распространяться только на компоненты и будут обнаружены намного быстрее. Полная сборка, по сути, просто объединит вместе уже объединенные компоненты, а также будет быстрее. Тогда вы можете запустить только некоторые тесты, чтобы убедиться, что правильные компоненты были разрешены.Ответы:
Сначала пара основных принципов: - Основные изменения всегда должны быть в ветви функций в вашей VCS. - Ветви компонентов должны проходить все тесты до объединения в магистраль. Добавленный - Берет всегда должен строить - Сломанные сборки требуют немедленного действия со коммиттера и / или остальную частью команды. - Неудачный тест должен прервать оставшиеся тесты, только если это критический тест.
Если вы, как команда, следуете этим методам и применяете их, например: «имя и позор», когда сборка нарушена, тогда вам следует поступить хорошо, так как любые коммиты, которые могут нарушить сборку, будут на ветви функций. К другим коммитам, которые нарушают сборку, нужно будет немедленно обратиться, и тогда вы получите результаты последующих тестов.
Вы также можете добавить автоматический тест последней «успешной» сборки (не обязательно такой, которая проходит интеграционные тесты) для тестов пользовательского интерфейса / веб-тестов в виде ночного запуска, который первым делом сообщает об этом утром.
источник
Не имеет никакого отношения к Scrum. Ваша сборка должна быть постоянно стабильной, независимо.
Никто не должен ничего проверять, если они не выполнили локальную сборку и не выполнили модульные тесты локально (и оба, конечно, прошли). Ваш локальный процесс сборки и тестирования должен быть чувствительным к изменениям и может пропускать тесты для кода, который не изменился.
Любой, кто вводит что-то, что приводит к сбою сборки или сбою модульного теста, должно быть публично опозорено . Если сборка нарушена, она должна быть немедленно исправлена.
источник
Ваша проблема в том, что тесты выполняются слишком долго. К счастью, закон Мура дал нам решение этой проблемы. Сегодня высокопроизводительные серверные процессоры могут легко иметь более 10 ядер (и более 10 HyperThreads). Таких процессоров может быть несколько на одном компьютере.
Если бы у меня были такие длительные тесты, я бы решил проблему с большим количеством оборудования. Я бы купил сервер высокого класса, а затем распараллелил тесты, чтобы тесты полностью использовали все ядра ЦП. Если ваши тесты сегодня однопоточные, то использование 10 ядер и 10 HyperThreds, вероятно, сделает тесты в 15 раз быстрее. Конечно, это означает, что они также используют в 15 раз больше памяти, поэтому на компьютере должно быть достаточно оперативной памяти.
Итак, несколько часов превратятся в 10-30 минут.
Вы не сказали, сколько времени занимает сборка, но стандартные инструменты сборки, такие как make, позволяют распараллеливать сборку. Если вы распараллелите свои модульные тесты, а типичный компьютер разработчика имеет 4 ядра и 4 HyperThreads, то менее чем 10 минут модульных тестов превратятся в менее чем 2 минуты. Итак, возможно, вы могли бы применить политику, согласно которой все должны запускать модульные тесты до совершения?
О неудачном завершении теста: остановка дальнейших тестов: не делайте этого на сервере сборки! Вам нужно как можно больше информации о сбое, и дальнейшие тесты могут выявить что-то важное. Конечно, если сборка не удалась, вы не можете запустить модульные тесты. Если разработчик запускает модульные тесты на своем компьютере, вы можете прервать работу при первом сбое.
Я не вижу никакой связи между Scrum и вашими проблемами. Проблемы действительно могут возникнуть при любом процессе разработки.
источник
Разве невозможно иметь больше установок Jenkins и заставить разработчиков проверять отдельный экземпляр Jenkins?
Я думаю, что лучшее решение здесь - сделать так, чтобы код прошел все тесты, прежде чем он будет проверен в ветке master и скомпилирован / протестирован основным экземпляром Jenkins. Не позволяйте людям проверять код, который нарушает сборку.
Я проверяю свой код в ветке разработки, проверяю, проходит ли он тесты, и создаю запрос на извлечение. Но вы, очевидно, могли бы, чтобы Дженкинс вытащил ветку функций и протестировал ее.
источник
Пункт (2) представляется наиболее болезненным, поэтому я остановлюсь на этом.
Возможно, пришло время разбить проект на несколько модулей.
https://en.wikipedia.org/wiki/Dependency_inversion_principle
Если один модуль не может быть собран, сборка для других модулей сможет продолжаться, пока эти другие модули могут зависеть от интерфейса и код, который составляет этот интерфейс, был успешно создан.
Это даст вам обратную связь о том, что могут произойти другие сбои сборки, так что у вас будет время исправить несколько сломанных модулей до того, как произойдет следующая сборка.
В общем, принципы SOLID предназначены для работы с библиотеками и создания проблем. Другими словами - этот набор принципов предназначен для решения именно тех проблем, с которыми вы сталкиваетесь.
Как примечание (см. Ответ juhist), вы не можете ускорить сборку (путем распараллеливания), если не разбиваете сборку на отдельные модули.
источник
Я думаю, что вашей команде не хватает одного из ключевых принципов схватки: готового, работающего программного обеспечения. PBI не должен быть помечен как выполненный, пока он не пройдет определение «Готово», установленное вашей командой. Определение Done различно для каждой команды, но, вероятно, будет включать в себя такие вещи, как:
Итак, по сути, ваша команда отмечает, что все сделано, а на самом деле не сделано. Это проблема сама по себе.
Кроме этого, все сводится к правильному управлению версиями. Если вы используете Git, то вся работа выполняется в локальном репозитории разработчика, и они не должны отправлять что-либо на удаленное устройство, если это «сделано» и потенциально может быть выпущено. Неполная работа никогда не должна передаваться в ваш главный репозиторий. Если разработчик должен работать над более долгоживущей ветвью функций и хочет перейти на удаленный доступ, чтобы убедиться, что он не потеряет свою работу, тогда он должен работать с разветвления, а затем вы объедините этот разветвление с основным, когда функция «выполнена» и потенциально может быть доступна для релиза - не раньше.
Для TFVC это немного сложнее, потому что все происходит на «дистанционном». Это означает, что разработчики должны всегда работать из веток, если это не быстрое решение. Здесь применяются те же правила, что и в Git: неполное программное обеспечение не фиксируется. Период. В правильно управляемом управлении версиями «main» всегда должен быть выпуская. Если был сделан коммит, который борчит "main", то вы делаете это неправильно.
источник