Предыдущий ролик Следующий ролик  

Видео урок: Интеграция рабочих потоков и непрерывная сборка

Принципы контроля версий

В некоторых системах контроля версий, таких как Team Foundation Server от Microsoft, есть функция под названием интегрированное отслеживание элементов рабочего процесса. Это означает, что вы можете разрешить тестировщикам связать ошибку с определенным изменением. Итак, разработчик, который пишет код, вносит изменение в исходный код, тестировщик выполняет некоторые тесты, находит ошибку и регистрирует ее. В данном случае, это называется созданием рабочего элемента. Этот рабочий элемент сейчас представляет собой конкретную проблему, которая существует в программном обеспечении. Далее разработчик исправляет ошибку, а затем, когда он коммитит изменение в системе контроля исходного кода, рабочий элемент также связывается и с этим сообщением коммита. Когда тестировщик получает уведомление о том, что рабочий элемент был обновлен, он получает не только сообщение коммита, написанное разработчиком, он также знает точно, какая ошибка связана с этим коммитом, и может убедиться, что ошибка действительно была исправлена.

Давайте рассмотрим пример. Это Диспетчер TFS в Visual Studio, здесь находятся рабочие элементы, и вы можете даже запросить рабочие элементы, связанные с конкретным пользователем. Здесь наш тестировщик создает новый рабочий элемент, здесь он создает новую ошибку. В Microsoft это называется Проблемой (Issue), для которой можно указать Приоритет (Priority), Статус (Status), написать Описание (Description), Добавить файлы (File Attachments) - все, что тестировщик сможет предоставить разработчику, чтобы помочь исправить ошибку.

Другая техника разработки, которая часто используется в командных сценариях, называется системами непрерывной сборки (continuous build systems). Это означает, что каждый раз, когда вы вносите изменения в исходный код, система перестроит продукт, чтобы подтвердить, что ваши изменения совместимы со всеми другими изменения, внесенными в систему, до того как набор изменений будет окончательно записан в хранилище. Например, разработчик изменяет исходный код, вносит изменения в систему и выполняет построение, чтобы убедиться, что внесенные изменения не вызывают ошибок. Система сборки даже запускает модульные тесты, чтобы убедиться, что они выполняются, перед тем зафиксировать изменения в хранилище.

Я знаю, до этого я сказал, что слова чекин и коммит обозначают одно и то же, но в этой конкретной системе термины расходятся и обозначают разные действия в этом многофазном процессе фиксации. Таким образом, разработчик вносит изменения, затем система выполняет проверку сборки, а затем, если проверка проходит успешно, изменения действительно коммитятся в хранилище. Как видите, в TFS есть ряд различных уровней качества сборки, которые вы можете установить, чтобы определить, когда код будет действительно закоммичен.

Когда вы начинаете использовать систему контроля версий, продумайте, как она может работать с другими инструментами, которые вы уже используете, например, с серверами сборки и системами отслеживания ошибок, чтобы использовать все преимущества комбинации этих инструментов.