Patch

Перевод Как мы выпускаем исправления к ПО в GitLab

05.09.2020 02:04:29 |

Автор: admin

Мы в GitLab обрабатываем исправления ПО двумя способами ручками и автоматически. Читайте далее о работе release manager по созданию и доставке важных обновлений с помощью автоматического развертывания на gitlab.com, а также исправлений для пользователей, которые работают со своими установками.

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

Но, как показывает практика, разработка ПО редко бывает без изъянов. При обнаружении ошибки или уязвимости в системе безопасности, release manager в команде доставки создает исправление для наших пользователей со своими установками. Gitlab.com обновляется в процессе CD. Мы называем этот процесс CD автоматическим развертыванием, чтобы не было смешивания с функцией CD в GitLab. Этот процесс может включать предложения из запросов на слияние, отправленных пользователями, клиентами и нашей внутренней командой разработки, так что решение скучной проблемы выпуска исправлений решается двумя весьма сильно различающимися способами.

Мы ежедневно обеспечиваем развертывание всего, что сделали разработчики, на всех окружениях, прежде чем выкатить это на GitLab.com, поясняет Marin Jankovki, старший технический менеджер инфраструктурного отдела. Воспринимайте выпуски для своих установок, как снимки для развертывания gitlab.com, для которых мы добавили отдельные действия по созданию пакета, чтобы наши пользователи могли использовать его для установки на своих мощностях.

Независимо от ошибки или уязвимости, клиенты gitlab.com получат исправления вскоре после их публикации, что является преимуществом автоматического процесса CD. Исправления для пользователей со своими установками требуют отдельной подготовки, выполняемой release manager.

Команда доставки усиленно работает над автоматизацией большинства процессов, связанных с созданием выпусков для сокращения MTTP (mean time to production, т.е. времени, затраченного на производство), промежутка времени от обработки запроса на слияние разработчиком до развертывания на gitlab.com.

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

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

Что делает release manager?

Члены команды ежемесячно передают роль release manager наших выпусков для пользователей на своих мощностях, включая исправления и выпуски безопасности, которые могут происходить между выпусками. Также они отвечают за переход компании на автоматическое, непрерывное развертывание.

Выпуски для установки на своих мощностях, а также выпуски gitlab.com используют похожие рабочие процессы, но работают в разное время, поясняет Marin.

В первую очередь release manager, независимо от типа выпуска, обеспечивает доступность и безопасность GitLab с момента запуска приложения на gitlab.com, включая гарантию того, что одинаковые проблемы не попадут в инфраструктуру клиентов со своими мощностями.

Как только в GitLab ошибка или уязвимость помечается исправленной, release manager должен оценить, что она попадет в исправления или обновления безопасности для пользователей со своими установками. Если он решит, что ошибка или уязвимость заслуживают обновления начинается подготовительная работа.

Release manager должен решить, готовить ли исправление, или когда его разворачивать и это сильно зависит от контекста ситуации, а пока машины не так хорошо управляются с контекстом, как люди, говорит Marin.

Все насчет исправлений

Что такое исправления, и почему они нам нужны?

Release manager принимает решение о выпуске исправления в зависимости от серьезности ошибки.

Ошибки различаются в зависимости от их серьезности. Так ошибки S4 или S3 могут быть стилистическими, например смещение пикселя или значка. Это не менее важно, однако тут нету особого влияния на чей-то рабочий процесс, а значит вероятность того, что исправление будет создано для таких ошибок S3 или S4, мала, поясняет Marin.

Однако уязвимости S1 или S2 означают, что пользователь не должен обновляться до последней версии, или есть значительная ошибка, влияющая на рабочий процесс пользователя. Если таковые попадают в трекер многие пользователи столкнулись с ними, поэтому release manager сразу же начинает подготовку исправления.

Как только исправление для уязвимостей S1 или S2 готово, release manager запускает выпуск исправления.

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

Когда накапливается много S4, S3 и S2 release manager смотрит контекст для определения срочности выпуска исправления, а при достижении некоторого их числа они все объединяются и выпускаются. Исправления или обновления безопасности после выпуска кратко описываются в сообщениях блога.

Как release manager создает исправления

Мы применяем GitLab CI и другие функции, например наш ChatOps, для создания исправлений. Release manager запускает выпуск исправления путем активации команды ChatOps на нашем внутреннем канале #releases в Slack.

/chatops run release prepare 12.10.1

ChatOps работает в Slack, чтобы активировать разные события, которые затем обрабатывает и выполняет GitLab. Например, команда доставки провела настройку ChatOps для автоматизации разных вещей для выпуска исправлений.

Как только release manager запускает команду ChatOps в Slack, остальная работа происходит автоматически в GitLab с использованием CI\CD. Между ChatOps в Slack и GitLab в процессе выпуска происходит двухсторонний обмен данными, поскольку release manager активирует некоторые из основных этапов процесса.

На видео ниже предоставлен технический процесс подготовки исправления для GitLab.

Как устроено автоматическое развертывание gitlab.com

Сам процесс и инструменты, используемые при обновлении gitlab.com, похожи на таковые, используемые при создании исправлений. Обновление gitlab.com требует меньше ручной работы с точки зрения release manager.

Вместо запуска развертывания с использованием ChatOps мы используем функции CI, например scheduled pipelines, с которыми release manager может запланировать выполнение определенных действий в требуемое время. Вместо ручного процесса есть конвейер, запускаемый периодически один раз в час, который скачивает внесенные новые изменения в проектах GitLab, упаковывает их и планирует развертывание, а также автоматически запускается тестирование, QA и другие необходимые шаги.

Итак, мы имеем много развертываний, запущенных в различных окружениях, до gitlab.com, а после того, как эти окружения будут в хорошем состоянии, и тестирование покажет хорошие результаты, release manager запускает действия по развертыванию gitlab.com, рассказывает Marin.

Технология CI\CD для поддержки обновлений gitlab.com автоматизирует весь процесс до момента, когда release manager должен руками запускать развертывание производственного окружения на gitlab.com.

Marin подробно рассказывает о процессе обновления gitlab.com на видео ниже.

Что еще делает команда доставки

Основное различие между процессами обновления gitlab.com и выпуском исправлений для клиентов на своих мощностях заключается в том, что последний процесс требует больше времени и большего количества ручной работы от release manager.

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

Одна из краткосрочных целей команды доставки уменьшить объемы ручной работы со стороны release manager для ускорения выпуска. Команда работает над упрощением, оптимизацией и автоматизацией процесса выпуска, что поможет быстрее избавиться от исправлений для проблем с низким уровнем серьезности (S3 и S4, прим. переводчика). Ориентация на скорость ключевой показатель производительности: надо уменьшать MTTP время, с приема запроса на слияние и до развертывания результата на gitlab.com с текущих 50 часов до 8 часов.

Команда доставки также работает над переходом gitlab.com на инфраструктуру на основе Kubernetes.

N.B. редактора: Если вы уже слышали о технологии Kubernetes (а я даже и не сомневаюсь, что слышали), но ещё не пощупали её руками, рекомендую поучаствовать в онлайн-интенсивах Kubernetes База, который пройдёт 28-30 сентября, и Kubernetes Мега, который пройдёт 1416 октября. Это позволит вам уверенно ориентироваться в технологии и работать с ней.

Это два подхода, преследующих одну и ту же цель: быстрая доставка обновлений, как для gitlab.com, так и для клиентов на своих мощностях.

Есть идеи и рекомендации для нас?

Каждый может принять участие в разработке GitLab, мы приветствуем отзывы от наших читателей. Если у вас есть идеи для нашей команды доставки не стесняйтесь создать заявку с пометкой team: Delivery.

Подробнее..

Категории: Kubernetes , Gitlab , Ci/cd , Devops , Блог компании southbridge , Patch , Release cycle

Partial Update library. Частичное обновление сущности в Java Web Services

17.02.2021 12:10:47 |

Автор: admin

Введение

В структуре веб-сервисов типичным базовым набором операций над экземплярами сущностей(объектами) является CRUD (Create, Read, Update и Delete). Этим операциям в REST соответствуют HTTP методы POST, GET, PUT и DELETE. Но зачастую у разработчика возникает необходимость частичного изменения объекта, соответствующего HTTP методу PATCH. Смысл его состоит в том, чтобы на стороне сервера изменить только те поля объекта, которые были переданы в запросе. Причины для этого могут быть различные:

большое количество полей в сущности;
большая вероятность одновременного изменения одного и того же объекта при высокой нагрузке, в результате которого произойдет перезапись не только модифицируемых полей;
невозможность или более высокая сложность изменения полей в нескольких или всех объектах в хранилище(bulk update);

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

Рассмотрим наиболее часто применяемые варианты решения задачи частичного обновления.

Использование обычного контроллера и DTO

Один из наиболее часто встречаемых вариантов реализации метода PATCH. В контроллере пришедший объект десериализуется в обычный DTO, и далее по стеку слоев приложения считается, что все поля в DTO со значением null не подлежат обработке.

К плюсам данного метода можно отнести "привычность" реализации.

К минусам относится во-первых потеря валидности значения null для обработки (после десериализации мы не знаем отсутствовало ли это поле в передаваемом объекте или оно пришло нам со значением null).

Вторым минусом является необходимость явной обработки каждого поля при конвертировании DTO в модель и далее по стеку в сущность. Особенно сильно это чувствуется в случае обработки сущностей с большим количеством полей, сложной структурой. Частично вторую проблему возможно решить с использованием ObjectMapper(сериализация/десериализация POJO, аннотированных @JsonInclude(Include.NON_NULL) ) ,а так же библиотекой MapStruct, генерирующей код конвертеров.

Использование Map<String, Object> вместо POJO

Map<String, Object> является универсальной структурой для представления данных и десериализации. Практически любой JSON объект может быть десериализован в эту структуру. Но, как мы можем понять из типов обобщения, мы теряем контроль типов на этапе компиляции (а соответственно и на этапе написания исходного кода в IDE).

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

Недостатки же в данном случае глобальны: потеря контроля типов на этапе написания исходного кода и компиляции, необходимость явного приведения типов, высокая сложность рефакторинга, обнаружение практически всех ошибок, связанных с типами данных и именованием полей только в runtime(тесты или реальный запуск приложения).

Использование JSON Patch и JSON Merge Patch

JSON Patch и JSON Merge Patch являются стандартизованными и наиболее универсальными методами описания частичного изменения объекта. Спецификация Java EE содержит интерфейсы, описывающие работу с обоими этими форматами: JsonPatch и JsonMergePatch. Существуют реализации этих интерфейсов, одной из которых является библиотека json-patch. Оба формата кратко описаны в статье Michael Scharhag REST: Partial updates with PATCH.

Достоинства метода: стандартизация, универсальность, возможность реализовать не только изменение значения в объекте, но и добавление, удаление, перемещение, копирование и проверку значений полей в объекте.

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

Partial Update library

Основной целью создания библиотеки стало объединение положительных и исключение отрицательных сторон первых двух методов из описанных: использование классических DTO в фасадах и гибкости структуры Map<String, Object> "под капотом".

Ключевыми элементами библиотеки являются интерфейс ChangeLogger и класс ChangeLoggerProducer.

Класс ChangeLoggerProducer предназначен для создания "оберток" POJO, перехватывающих вызовы сеттеров и реализующих интерфейс ChangeLogger для получения изменений, произведенных вызовами сеттеров в виде структуры Map<String, Object>.

Для дальнейших примеров будут использоваться вот такие POJO:

public class UserModel {private String login;private String firstName;private String lastName;private String birthDate;private String email;private String phoneNumber;}@ChangeLoggerpublic class UserDto extends UserModel {}

Вот пример работы с такой "оберткой":

ChangeLoggerProducer<UserDto> producer = new ChangeLoggerProducer<>(UserDto.class);UserDto user = producer.produceEntity();user.setLogin("userlogin");user.setPhoneNumber("+123(45)678-90-12");Map<String, Object> changeLog = ((ChangeLogger) user).changelog();/*    changeLog in JSON notation will contains:    {        "login": "userlogin",        "phoneNumber": "+123(45)678-90-12"    }*/

Суть "обертки" состоит в следующем: при вызове сеттера его имя добавляется в Set<String>, при дальнейшем вызове метода Map<String, Object> changelog() он вернет ассоциативный список, ключом в котором будет имя поля, а соответствующим ключу значением будет объект, возвращенный соответствующим геттером. В случае, если объект, возвращаемый геттером реализует интерфейс ChangeLogger, то в значение поля пойдет результат вызова метода Map<String, Object> changelog().

Для сериализации/десериализации "оберток" реализован класс ChangeLoggerAnnotationIntrospector. Это класс представляет собой Annotation Introspector для ObjectMapper. Основной задачей класса является создание "обертки" при десериализации класса, аннотированного @ChangeLogger аннотацией библиотеки и сериализацией результата вызова метода Map<String, Object> changelog() вместо обычной сериализации всего объекта. Примеры использования ObjectMapper с ChangeLoggerAnnotationIntrospector приведены ниже.

Сериализация:

ObjectMapper mapper = new ObjectMapper.setAnnotationIntrospector(new ChangeLoggerAnnotationIntrospector());ChangeLoggerProducer<UserDto> producer = new ChangeLoggerProducer<>(UserDto.class);UserDto user = producer.produceEntity();user.setLogin("userlogin");user.setPhoneNumber("+123(45)678-90-12");String result = mapper.writeValueAsString(user);/*    result should be equal    "{\"login\": \"userlogin\",\"phoneNumber\": \"+123(45)678-90-12\"}"*/

Десериализация:

ObjectMapper mapper = new ObjectMapper.setAnnotationIntrospector(new ChangeLoggerAnnotationIntrospector());String source = "{\"login\": \"userlogin\",\"phoneNumber\": \"+123(45)678-90-12\"}";UserDto user = mapper.readValue(source, UserDto.class);Map<String, Object> changeLog = ((ChangeLogger) user).changelog();/*    changeLog in JSON notation will contains:    {        "login": "userlogin",        "phoneNumber": "+123(45)678-90-12"    }*/

Используя ObjectMapper с ChangeLoggerAnnotationIntrospector мы можем десериализовать пришедший нам в контроллер JSON с полями для частичного апдейта и далее передавать эти данные в подлежащие слои сервисов для реализации логики. В библиотеке присутствует инфраструктура для реализации мапперов DTO, Model, Entity с использованием "оберток". Пример полного стека приложения реализован в тестовом проекте Partial Update Example.

Итог

Partial Update library позволяет с рядом ограничений реализовать наиболее типичную задачу частичного изменения объекта, используя максимально близкий к типовому способ организации стека приложения. При этом универсальность ассоциативного списка объединена с сохранением контроля типов данных в процессе написания исходного кода и компиляции, что позволяет избежать большого числа ошибок в runtime.

В настоящее время функционал имеет ряд ограничений:

реализован только простейший маппинг "поле в поле", что не позволяет автоматизировать ситуации с разными именами одного и того же поля в DTO, Model, Entity;
не реализован модуль интеграции со Spring, в связи с чем для реализации сериализации/десериализации "оберток" DTO необходимо реализовать конфигурацию(как в примере), добавляющую ChangeLoggerAnnotationIntrospector в стандартный ObjectMapper контроллера приложения;
не реализованы утилиты формирования SQL/HQL запросов для bulk update операций с БД;

В последующих версиях планируется добавление недостающего функционала.

Формат данной статьи не позволяет более детально рассмотреть инфраструктуру для создания мапперов и показать применение библиотеки в типичном стеке приложения. В дальнейшем я могу более детально разобрать Partial Update Example и уделить больше внимания описанию внутренней реализации библиотеки.