Путем запуска набора локальных модулей и функциональных тестов инженеры Etsy могут с большой долей вероятности гарантировать работоспособность внесенных в ПО изменений на локальном уровне. Также они могут протестировать изменения на отладочном сервере. При этом используется Jenkins-кластер, который практически идентичен производственному кластеру непрерывной интеграции (CI). К тому же Jenkins-кластер обладает дополнительным преимуществом: для перехода к мастер-ветви не нужен дополнительный код. После успешного прогона тестов инженеры получают дополнительные гарантии того, что изменения не приводят к нарушению работоспособности тестов.
В зависимости от масштаба и сложности изменений новый инженер может отправить запрос на принятие изменений кода или попросить кого-либо из коллег просмотреть код. Эта процедура не является обязательной для каждого изменения и зачастую осуществляется на усмотрение сотрудника. В среде Etsy, которой присуща высокая степень доверия и где отсутствует практика напрасных обвинений, сотрудникам предоставляется право принимать решение о необходимости просмотра кода. Новым или менее опытным сотрудникам предлагаются рекомендации, помогающие идентифицировать изменения, заслуживающие просмотра кода, а также определить, кто именно должен заниматься этой работой. Поскольку в то время Кэтрин только что приняли на работу в Etsy, более опытный коллега просматривал внесенные ею изменения перед выполнением развертывания этих изменений.
После прохождения внутренних и пробных тестов разработчик присоединяется к очереди магазинного типа Etsy, чтобы выполнить развертывание изменений в производственной среде. Если несколько разработчиков готовы развернуть изменения одновременно, для координирования развертывания изменений в системе управления очередью используется Internet Relay Chat (IRC) и IRC-бот. Как только подходит очередь Кэтрин, она подтверждает изменения в мастер-ветви репозитория, в которой она работает. Для развертывания изменений на сервере QA в Etsy используется среда Deployinator. Благодаря применению этой среды выполняется автоматическое создание QA-сервера и выполняется полный набор тестов CI.
После успешного завершения создания QA-сервера и прогона тестов Кэтрин выполняет быструю ручную проверку QA-версии сайта и журналов, чтобы идентифицировать проблемы, которые не были обнаружены в результате выполнения автоматизированных тестов. На этом этапе Кэтрин также использует среду Deployinator, чтобы развернуть код на производственной платформе и убедиться в отсутствии проблем с тестами и журналами. Если же в результате выполнения тестов проблемы не идентифицированы, выполняется дополнительная проверка с помощью одной из многочисленных графических панелей либо программы мониторинга Nagios. В случае обнаружения проблем с помощью этих средств пользователи получат соответствующее уведомление. Помимо этого, во многих группах выполняются собственные проверки, реализуемые в запланированном режиме с помощью Nagios. В результате обеспечивается слаженная работа всех членов группы. Если даже возникают какие-то проблемы, коллеги работают совместно над их устранением, учатся на своих ошибках, не обвиняя других постфактум в возникших проблемах.