Что я только что прочитал? Как оригинальное авторское исследование (в негативном смысле, т.к. не приведены никакие авторитетные источники) истории двойной бухгалтерии относится к хабу История ИТ? Что эта статья делает на Хабре?
Вполне возможно, т. к. нативный мейл-рушный мессенджер (хоть на вид и не очень) вполне себе уже по-интереснее, чем асько, как с точки зрения пользователей, так и (мне кажется) с точки зрения компании…
Интеграционный сервер собирает все ревизии или ревизию, которую указывает, например, Test Lead
QA команда решает сама или с помощью менеджера, какую версию им тестировать
Разработчик обновляется не на “последнюю версию”, а решает сам, на основании какой ревизии должен быть создан новый коммит
Мне кажется, «решает сам» не вполне отвечает на вопрос «на какой ревизии тестировать» или «кто решает, какая ревизия является „главной головой“». Вы правы, что это зависит от процесса разработки. У вас были замечательные иллюстрации, а вот вывод получился скомканным. Есть ли у вас что предложить конкретного, конкретный сценарий?
// Плюс, вопросы: как этот самый разработчик должен решать, от какой ревизии ему плясать. Кто потом будет все эти головы мержить?
У нас несколько разных сборок — тесты юнитовые для клиента, для сервера, тесты функциональные серверные. Единственное, мы пока не осилили интеграционные тесты клиент-сервер. Получается слишком хрупко. Специфика проекта — клиент-серверная архитектура с упором на отзывчивость связки клиент-сервер и устойчивость сервера, супер-тослтый клиент :)
Ну, из того, что я вижу по вашим высказываниям, есть несколько процессных проблем. В частности — разделение на «разработчиков» и «тестировщиков». Тестировщики — такие же разработчики, как и программисты и аналитики, и другие участники создания продукта.
Ручной запуск тестов — моветон :)
Зафига их запускать, если демо-билд уже состоялся? Получается, что эти N тысяч тестов — приемочные и больше не используются в процессе разработки? Так тогда у них низкий KPI… :(
Ясно, что если тесты запускаются раз в две недели, там будет ад и содомия. Я сейчас на очень напряженном проекте — по 200 — 300 коммитов в день. Если крупно не повезет и билдер ляжет на полдня — разбираться в паре сотен пофейленных тестов — занятие неблагодарное. Рекомендую сокращать циклы до 1 билд на коммит в идеале. :)
Ну, во-первых, Continuous Integration — если падение тестов «заметили не сразу», не понятно, зачем они вообще нужны.
Во-вторых, есть история изменений файла. По ней погулять — тоже не составит проблемы.
В-третьих, если мы «просто откатимся» на древнюю ревизию, это ничем не поможет от системного изменения логики. Потому что окружающий «обвязочный» код уже поменялся, поменялись интерфейсы системы под тестом, объекты тестирования. :)
Кстати, инспекции можно так же запускать на билдерах в качестве элемента сборки. :)
Может быть, мы о разных вещах говорим? Какие такие изменения в логике тестов можно предотвратить/исправить инспекциями или откатом к старой ревизии? Можете конкретный пример привести?
Я так и не понял, какую проблему решает это инструмент, которую бы не решали VCS.
Проблема, как понимаю ее я:
— есть файл с тестом.
— есть глобальный рефакторинг, который меняет валидное поведение
— куча тестов падает, потому что расчитывали на другое «валдиное» поведение.
Стандартное решение:
— прогнать весь набор файлов.
— проанализировать.
— все, которые упали из-за рефакторинга — поправить; или откатить рефакторинг.
Так? Какую проблему решает этот инструмент лучше, чем VCS?
// Плюс, вопросы: как этот самый разработчик должен решать, от какой ревизии ему плясать. Кто потом будет все эти головы мержить?
Ручной запуск тестов — моветон :)
Зафига их запускать, если демо-билд уже состоялся? Получается, что эти N тысяч тестов — приемочные и больше не используются в процессе разработки? Так тогда у них низкий KPI… :(
Во-вторых, есть история изменений файла. По ней погулять — тоже не составит проблемы.
В-третьих, если мы «просто откатимся» на древнюю ревизию, это ничем не поможет от системного изменения логики. Потому что окружающий «обвязочный» код уже поменялся, поменялись интерфейсы системы под тестом, объекты тестирования. :)
Кстати, инспекции можно так же запускать на билдерах в качестве элемента сборки. :)
Может быть, мы о разных вещах говорим? Какие такие изменения в логике тестов можно предотвратить/исправить инспекциями или откатом к старой ревизии? Можете конкретный пример привести?
Проблема, как понимаю ее я:
— есть файл с тестом.
— есть глобальный рефакторинг, который меняет валидное поведение
— куча тестов падает, потому что расчитывали на другое «валдиное» поведение.
Стандартное решение:
— прогнать весь набор файлов.
— проанализировать.
— все, которые упали из-за рефакторинга — поправить; или откатить рефакторинг.
Так? Какую проблему решает этот инструмент лучше, чем VCS?