Все знают, как разрабатывать продукты для клиентов. Другое дело, когда задачу в разработку приносят не продакты, а коллеги из других команд: например, хотят автоматизировать свои процессы или внедрить новую систему. 

Они остаются наедине со своими проблемами. Идут к разработчикам — те просят ТЗ от аналитиков. Идут к аналитикам — те просят требования от службы безопасности, и это только начало. 

После того как проект описан, нужно выбить ресурсы на его разработку, доказать его важность и эффективность. Для многих коллег не из IT это неподъемные задачи. 

Внутри Lamoda Tech мы задумались о том, как не забивать на такие идеи. Эти проекты могли бы ускорить процессы и принести значительную выгоду компании. Но они редко доходят до реализации: слишком много усилий для этого нужно приложить. Большинство заказчиков сходят с дистанции задолго до финиша. 

В этой статье мы рассмотрим, как с помощью Open Source-утилиты werf собрать Docker-образ простого приложения и развернуть его в кластере Kubernetes, а также с легкостью накатывать изменения в его коде и инфраструктуре.

Мы поговорим об общих принципах работы с werf при использовании ее разработчиками, поэтому в качестве примера приложения используем небольшой эхо-сервер на основе shell-скрипта, который будет возвращать в ответ на запрос по адресу /ping строку Hello, werfer!. В следующих материалах будет рассмотрена работа и с «настоящими» приложениями, основанными на распространенных фреймворках на разных языках, но для начала сфокусируемся на общем подходе к разработке с использованием утилиты werf.

В компании $WORK мы столкнулись с необходимостью "плавного завершения работы" наших сервисов. Грациозное завершение работы позволяет убедиться в том, что система правильно финиширует перед завершением. В качестве аналогии можно привести ситуацию, когда человек пытается правильно завершить телефонный разговор перед тем, как перейти к следующей встрече, а не просто бросает трубку на середине фразы.

В этой главе мы расскажем о том, что такое плавное завершение работы в контексте HTTP-сервера, а также о том, как писать "приемочные тесты", чтобы быть уверенным в поведении своего кода.

После прочтения этой главы вы будете знать, как совместно использовать пакеты с отличными тестами, сократить усилия по сопровождению и повысить уверенность в качестве своей работы.