Привет, Хабр! 

Впервые с вопросом анонимизации данных мы широко столкнулись при работе с динамическими окружениями.

Не секрет, что разработка даже небольшого проекта тесно связана с инфраструктурой, поскольку любая программа требует наличия определённого окружения. Часто таких окружений требуется несколько — одно под прод, а остальные — под разные нужды, например, тестирование. Иногда эти среды даже могут быть динамическими — когда вместе с новым бранчем создаётся окружение, в котором запускается разрабатываемая версия приложения и всё необходимое для неё, а после того как бранч вливается в main, эта среда и все её данные удаляется. 

И вот как раз о данных (а точнее о базах данных) в таких средах и хотелось бы поговорить. А именно — где и как их взять, как сделать их максимально приближенными к боевым и как защититься от их утечки. Для решения этих задач мы в Nixys используем собственный инструмент — nxs-data-anonymizer. Хотим поделиться им с вами.

Понятие DevOps знакомо многим, но в своей практике я часто наблюдаю такую ситуацию, когда соискатель на должность DevOps-инженера в нашу компанию не может ответить на вопрос “А что же такое DevOps?”. В данной статье я хочу упорядочить и структурировать знания и основные понятия DevOps. Ещё раз обозначить какие процессы там существуют, для чего они и с чего начать внедрение DevOps у себя в проекте.

От переводчика: при разработке ПО у программистов, какого бы уровня они ни были, нередко возникает желание реализовать тот или иной фрагмент программы более красиво и удобно. Когда, глядя на код, интуитивно чувствуешь: этот кусок точно можно сделать изящнее, начинаешь либо вспоминать best practice для решения таких задач, либо искать их в инете, либо придумывать своё решение. Недавно я сам столкнулся с подобной ситуацией и нашёл, казалось бы, очевидное решение, но, тем не менее, ранее я им не пользовался. Вот им бы хотелось поделиться с сообществом в представленном ниже переводе очень небольшой статьи.

В этой статье подробно объясняется, как решать проблемы, связанные с совместимостью баз данных при деплое. Мы расскажем, что может произойти с вашими приложениями на проде, если вы попытаетесь выполнить деплой без предварительной подготовки. Затем мы пройдемся по этапам жизненного цикла приложения, которые необходимы, чтобы иметь нулевое время простоя (прим. пер.: далее — zero downtime). Результатом наших операций будет применение обратно несовместимого изменения базы данных обратно совместимым способом.

Прим. перев. — Этой статьёй мы начинаем цикл переводов, посвященных теме Zero Downtime Deployment. Следующие публикации осветят вопросы деплоя новых версий приложения с БД и деплой в Kubernetes.

Несмотря на то, что техническое решение, описываемое ниже достаточно спорно, целью данной статьи является знакомство читателя непосредственно с подходом Blue-Green деплоя, который, кстати, применим не только к приложениям Spring.

Целью Blue-Green деплоя является устранение простоев во время развертывания новой версии приложения.

Простой связан с недоступностью серверов, когда новая версия приложения устанавливается для замены старой. Идея Blue / Green deployment заключается в развертывании новой версии приложения в некоем отдельном месте, где можно проводить тестирование, вплоть до момента принятия окончательного решения о переключении на неё как на основную.

Пакет context в Go полезен при взаимодействиях с API и медленными процессами, особенно в production-grade системах, которые занимаются веб-запросами. С его помощью можно уведомить горутины о необходимости завершить свою работу.

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

(Прим. пер.: Контекст используется во многих пакетах, например, в работе с Docker).