Релиз

Сегодня я решил написать о самых главных нововведениях в Kotlin 1.4.0. Думаю, что начинающим Android разработчикам будет очень интересна данная тема и они смогут применить новые фишки в своих приложениях. Также, я надеюсь, что моя статья будет полезна и для профессиональных разработчиков, которые очень любят и помогают развивать Kotlin.

Основные темы, которые я затрону:

• Нововведения в синтаксисе

• Новые инструменты в IDE

• Новые компилятор

• Качество и производительность

Ну что ж, предлагаю вам налить себе кофе или чай, запастись сладеньким и можно начинать)

Немного о релизах Kotlin

На момент написания статьи самыми новыми релизами были:

Нововведения в синтаксисе

SAM - интерфейсы

Одной из самых важных и довольно полезных фишек является добавление нового синтаксиса для SAM интерфейсов (SAM - Single Abstract Method, также интерфейс с одним методом называют функциональным).

Чтобы указать компилятору Kotlin о том, что перед нами SAM интерфейс нужно использовать ключевое слов fun, как ниже в примере:

fun interface ItemSelectListener {fun onItemSelect(position: Int): String}val items = listOf("Item 1", "Item 2", "Item 3")val myListener = ItemSelectListener { position ->items[position]}fun main() {    print("selected item -> ${myListener.onItemSelect(0)}")}

Одно из применений: передача обработчиков событий в адаптер RecyclerView для отслеживания нажатия на элемент списка.

Данный подход сокращает количество строк кода и вводит дополнительные удобства.

Явный API режим

Kotlin предлагает новый явный API режим для разработчиков библиотек.

Основные моменты:

1. Явный API режим помогает делать API библиотек чистым и последовательным

2. Накладывает различные требования и ограничения на публичные API:

   1. Строгое использование модификаторов доступа

   2. Явное указание типов для свойств и функций, которые являются частью публичного API

3. Некоторые определения исключены из проверок: свойства data классов, первичные конструкторы и т.д.

Более подробно

Смешанные именованные и позиционные параметры

Довольно легко объяснить на примере. До Kotlin 1.4.0 нельзя было делать так:

fun foo(a: Int, b: String = "", c: Int) {}fun main() {foo(a = 10, "Hello, World", c = 100000)}

В данном примере мы сначала указываем именованный параметр, а потом позиционный (строка "Hello, World"). В ранних версиях Kotlin нужно было всегда указывать сначала позиционные.

Конечная запятая

Довольное удобно при обмене строк или копировании параметров функций

fun reformat(str: String,              wordSeparator: Char = ' ', // конечная запятая) {  // TODO}

Улучшения вызываемых ссылок на функции

Теперь вы можете использовать ссылки на функции, которые имеют default аргументы:

fun foo(a: Int = 0): String = "value -> $a" // параметр 'a' имеет значение по умолчанию 0fun apply(f: () -> String): String = f()fun main() {    println(apply(::foo))}

Вы можете использовать ссылки на функции, которые возвращают любое тип, там где требуются функции возвращающие Unit.

Например у нас есть функция foo, которая принимает другую функцию, которая ничего не возращает (Unit). Мы можем передать ей любую ссылку на функцию, у которой совпадает количество аргументов, а возвращаемый тип может быть любой:

fun foo(f: () -> Unit) { }fun returnValue(): Int = 42fun main() {    foo { returnValue() } // Так было до Kotlin 1.4.0    foo(::returnValue) // начиная с Kotlin 1.4.0 можно передать сюда функцию,     // которая возвращает любой тип}

Вы можете адаптировать ссылки на функции, когда передается переменное количество аргументов:

fun foo(a: Int, vararg words: String) {}fun useCase0(f: (Int) -> Unit) {}fun useCase1(f: (Int, String) -> Unit) {}fun useCase2(f: (Int, String, String) -> Unit) {}fun test() {    useCase0(::foo)     useCase1(::foo)     useCase2(::foo) }

В дополнение появилась поддержка передачи ссылки на функцию, там где используется ключевое слово suspend

fun lockUI() {}fun takeSuspend(f: suspend () -> Unit) {}fun test() {    takeSuspend { lockUI() } // до Kotlin 1.4.0    takeSuspend(::lockUI) // В Kotlin 1.4.0 можно сделать так}

Использование breakandcontinueвнутриwhenвыражений, включенных в цикл for

В Kotlin 1.4.0 вы можете использовать ключевые слова break и continue в операторе when, когда он вложен в циклfor (до этого нужно было создавать метки, более подробно)

fun foo(numbers: List<Int>) {    for (num in numbers) {        when {            num % 2 == 0 -> continue            num == 10 -> break            else -> println(x)        }    }}

Новые инструменты в IDE

Новое гибкое окно создания проекта

Теперь вы можете создавать и конфигурировать различные типы проектов Kotlin более гибко и специфично:

Новое окно создания проекта позволяет:

1. Выбрать шаблон проекта (в будущем будет добавлено больше шаблонов)

2. Выбрать систему сборки (Gradle, Maven)

3. Посмотреть структуру проекта до его создания

4. Добавить/удалить модули, поддерживаемые данным шаблоном проекта

5. Настроить JVM версию, framework для тестирования и другие вещи.

Отладчик Корутин

Очень много разработчиков на Kotlin используют всеми известные корутины (а как же без них).

До Kotlin 1.4.0 приходилось полагаться на введение логов и умственные усилия разработчика, чтобы отлаживать программы с наличием корутин.

Теперь появился новый инструмент, который находится в Debug Tool Window в Intellij IDEA, который позволяет:

1. Легко проверить состояние каждой корутины

2. Посмотреть значения локальных и захваченных переменных для корутин

3. Посмотреть полный стек создания корутины, а также стек внутри корутины (все фрэймы с локальными переменными)

4. Также можно получить полный отчет, воспользовавшись функцией Get Coroutines Dump

Новый компилятор

Главной целью создания нового компилятора было соответствие характеристикам:

1. Скорость

2. Создание общего интерфейса для разных платформ, которые поддерживает Kotlin

3. Обеспечение API для расширения компилятора

Основные улучшения по сравнению с предыдущим компилятором:

1. Новый более мощный алгоритм для автоматического вывода типов с поддержкой более сложных сценариев вывода типов и с улучшенниями для делегированных свойств. (данный алгоритм уже был доступен в версии Kotlin 1.3 при указании дополнительных опций, в новой версии он будет использоваться по умолчанию). Вы можете найти более десятка исправленных багов и ошибок в новом алгоритме на YouTrack

2. Унифицированный backend компилятора (в Kotlin есть несколько backend, такие как: Kotlin/JVM, Kotlin/JS и Kotlin/Native. Последний был основан на промежуточном представлении (IR) для Kotlin кода)

Сейчас компания JetBrains работает над более производительной frontend реализацией.

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

Качество и производительность

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

Основные улучшения:

1. Было исправлено более 60 ошибок производительности, включая большое количество случаев зависания IDE и утечек памяти

2. Прирост в скорости IDE, который можно увидеть, пройдя по ссылке (здесь время подсвечивания синтаксиса Kotlin при открытии большого проекта). Также на рисунке ниже показано время срабатывания автодополнения (которое уменьшилось по сравнению с предыдущими релизами)

3. И многие другие, которые напрямую связаны с созданием нового компилятора.

Немного полезных ссылок

1. Информация о релизе Kotlin 1.4.0 на блоге JetBrains

2. Нововведения на официальном сайте Kotlin

3. Kotlin 1.4.0 Online Event (на английском)

4. Статистика от StackOverflow Survey 2020

5. Cтатистика от JetBrains

Несколько лет назад вOzonмежду двумя релизами приложения на одной платформе могло пройти три месяца.Мы планировали, что хотим выпуститься с определенной большой фичей и пока еёне сделаем не релизим.

С чем мы столкнулись, пока выпускали релизы по этой схеме:

1. Сложно спрогнозировать, когда выйдетфича.Ок,мы как-топрикидывалисроки, ночембольшебыл разрабатываемый функционал, тем сложнееточно оценить срок.Трекатьпрогресс фичитоже не очень удобно, потому что оно там делается,и промежуточныебилдыс чем-то готовым для посмотретьсложнособирать.

2. Долгоправитьбаги.Вкоде они могутбыть исправленыбыстро. А вотдо пользователейфиксдоходит уже вместе с той самой глобальной фичей.

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

4. Долго релизить мелкие фичи. Какие-то улучшения могут занимать немного времени на разработку, но быть важными для пользователей и бизнеса. Точно так же, какисправления багов в пункте выше, для релиза они будут ждать того монстра, которого мы пилимтримесяца.

5. Невыносимо долго проводить регрессионное тестирование. Всё,что было переделаноза несколько месяцев,мы будем проверять, чинить, перепроверять, чинить, перепроверятьНу, вы поняли

6. Многохотфиксов. Чем больше число и объем изменений, тем сложнеебудет найти все баги перед релизом. Вот и появляютсяхотфиксы. Ещёза такой долгий срок разработки может прилететь какая-то очень срочная фича, ждать нельзя надо срочно выпускать(например, поддержать разрешение на отслеживание или добавить что-то по срочному рекламному контракту).

Проблеммного,и они все значимые. Когда бизнеспришёл к нам и сказал, что надо релизить быстрее мы уже ожидали этого. Но не ожидали, что они скажут: Релизьте раз в неделю.

Тут у насслучиласьстадия отрицания:Мы не успеем всёпроверить, никаких фичей в релиз не попадет, Apple ревьюит о-го-госколько.Зачем, почему, может,не надо?.В ответ мы услышали: Релизы раз в неделю.

Сокращаем время выпуска релиза: первая попытка

Решили, что надодвигаться к целиитерационно.

Сначала научитьсявыпускать релизхотя быкопределённойдате. Первой попыткой был план успетьзарелизитьза месяц. Условно,мы решили 1 мая, что следующий релиз должен выйти 1 июня.

Ок, дата есть. Прикинули, что неделя уходит на регресс. На разработку остается три недели. Запланировали работына весь срок девелопмента.

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

Идёт первый месяц. Работаем. Пилим фичи, тестируем. Все заряжены.Но в итоге получили: тотобъём работ, который запланировали разработать за три недели, закончили под конецчетвёртой. Стали искать, где же выиграть время,нашли только один варианттестирование. Как могли, сократили регресс, но всёравно нашлинесколько критичных багов. В итогев зависимости от платформы с релизом опоздали на неделю-полторы.

Вторая попытка: нужно что-то менять

Да, мы решили, что нужны изменения. Но поменяли не процессы, а... сроки. Раз тяжело планировать на месяц давайте запланируем релизчерездве недели! Меньше успеем сделать фичей, быстрее проведем регрессионное тестирование - проще будет запланировать объем работ.

Тем временемтестировщикипродолжают писатьавтотесты

Пробуем всёравно каждый раз не успеваем.

Стали анализировать,из-за чегоне выходит уложиться в срок:

1. Неправильно оцениваем время на разработку.

2. Блочимсябекендом от этого тормозится и разработка, и тестирование.

3. Продактыпоздно вносятпоследниеправки в ТЗ.

4. Не учитываем время на починкубагов.

У нас был план:то, что не готово к началу тестирования в релиз неидёт. Но он не сработал.Приходилипродактыи говорили, что две недели ждать следующего релиза они не могут. Потомуходиливыше,и оттуданамговорили, что, да, надо доделать.

И тут пришлиQA.Сказали, что при двухнедельных релизахскоупнеособосократился.

Разработчиков много, они разделены по разномуфункционалуи задвенедели успеваютнакомититьпрактически во все компоненты. Стало понятно, что несмотря на то, что мыНИ РАЗУне успели в срок ни при месячном релизе, ни при двухнедельных пора двигаться дальше.

Недельные релизымыидём к вам!

Прежде всего надо было составить календарь наших действий на неделю. По разработке получилось так:

Меняемся в тестировании

Чтобы всёэто поддержать со стороныQA, пришлось ротировать обязанности тестировщиков по неделям. Одну неделю тестер проверяетфичи, вторую занимается написанием кейсовиавтотестов,участвует врелизномтестировании.При этомрелизноетестирование получилось сократить где-то до дня на каждую платформу.

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

Чтобы разработка не зависала на начальных этапах, мы выработали требования кфиче, которуюберём в работу у неёдолжныбыть в наличии

1. Дизайн;

2. Бекенд;

3. Контракт.

Если чего-то из этого нет смысла братьфичув разработку на мобильной платформе тоже нет.

Дальше встал вопрос о том, когда же можно включатьфичув релиз. Получились такие правила:

1. Бекендфичидолжен быть напродакшене.

2. К началурелизноготестирования нет критичныхбагов(ни на фронте, ни набекенде).

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

Меняемся в разработке

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

Ещёмы постоянно автоматизируем процессы, чтобы разработчикам надо было меньше отвлекатьсяна какие-то рутинные вещи,и они могли сконцентрироваться на разработке.

Тикетавтоматом двигается по статусам. Запушилкоммит перешел вinprogress.Создалmergerequest перешел вcodereview.ПрошелreviewпопалвQA.

Втикетеавтоматически проставляется версия релиза, куда он попал и номербилда.

По каждой сборке запускаютсяUI-автотестыпозатронутомуфункционалу.Это тоже определяется самопо измененным файлам вmergerequest.В результате репорт попадаетвкомментарийтикета вJira.

Дажеmergerequestна влитие эпика вdevсоздаётсяпросто по принятию продактом фичивJira.Если нет конфликтов, то и вливается сам.Релиз сам закрывается, а новый самсоздаётся.

QA Notes

Ещёмы ввели требования к разработчикам писатьQANotes.Там указывается:

1. Что было сделано.

2. Что могло быть задето.

3. Приложены скриншоты или видео.

4. На какой среде удалось проверить.

5. Для багаещёпричина, из-за чегосломалось(в идеалетикет, которыйпривёл к такому поведению).

QANotesпозволили значительно ускоритьтестированиеиревьюкода. А ещёдали нам скрытый бонус:пропалиреопеныотQAиз-закрешейна старте.

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

Автотестыраньше находят баги. Теперь не надо ждатьрелизноготестирования, чтобы увидеть проблемы после интеграции. Прогоныавтотестовпроисходят после каждоговливания эпика вdev,а такжекаждуюночь. Еслинадо, то можно запустить на эпик-веткедо вливания вdev. Раньше нашли баг раньше исправили.

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

А еще добавиласьротируемаяроль QAза релиз.Этоттестировщикгде-то раз вдватримесяцаделаетповторяющиесявещи:

1. Составляет наборрелизныхтестов.

2. Распределяет нагрузку команды тестирования пофичам. Если видит, что у одних сейчас малотикетов, а другие не успевают может перекинуть кого-то в помощь.

3. Напоминаеттестировщикампосмотретьотчёты поавтотестамнарелизномбилде.

4. Пушитпересборкурелиз-кандидатов, если что-то добавилось.

5. После релиза неделюмониторитпаденияи отвечает на запросы поддержки.

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

Автоматизация помогает контролировать стабильность среды с помощью выполнения тестов после изменения кода приложения:

Мы также проверяем, что новыеавтотестыне ломают существующие:

Новая схема релиза мобильных приложений

У нас стало значительно меньшехотфиксов.Релизы теперь чаще впять-десять раз, но хотфиксим мы реже, чем раньше.Причины две.Во-первых,получается делать более стабильные релизы.Во-вторых, если это не что-то невероятно критичное, то фикс, скорее всего, сможет подождать неделю до следующего релиза.

Теперь мы спокойнее переносимфичи. Неприятно, когда не успели, но перенос выхода фичи на неделю воспринимается спокойнее, чем на более долгий срок.

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

И главное. Мы теперьукладываемсяв сроки. Всегда. С первой попытки выпустить релиз за неделю мы успели это сделать. И с тех пор вот уже два года приложениеOzonобновляется раз в неделю, принося новыефичи, исправления ошибок.

Какиеестьсложности

В первую очередь этонепростойрефакторинг. Когдавмерживодинкоммит, вам надо перепроверить всёприложение.Сейчас мы прежде всеговливаемтакое по понедельникам-вторникам, чтобырефакторингмаксимально настоялся вdev, накрутилсяавтотестамии был потроган при тестированиифичей.

Ещё однасложностьпраздники,из-за которых рабочая неделя из пяти дней сокращается дочетырёх. Тут появляется больше риска,т.к.обычно мырелизимнатретий-четвёртыйдень после отрезаниярелизнойветкииостаётсяещёдень на мониторинг.Тогда какздесь обычно релиз происходит уже в последний рабочий день. Спасибо, фичефлагами процентной раскатке.

Что ещёможно улучшить

Прежде всего хочется научиться ещёраньше раскатывать билды на пользователей. Найти тестовыесегменты, на которые можно катить до началарелизноготестирования. Но это рискимиджевыхи денежныхпотерь.Такихсуперлояльных пользователейнам ещё только предстоитпоискать.Если вдруг вамможет быть этоинтересно пишите, добавим вас в сегмент бета-тестировщиков.

Ещёмы никогда не останавливаемся в автоматизации процессов. Постоянно находим возможность убрать ручную рутину. И покрываемавтотестамивсёбольшефункционала.

Для себя мы выработали такие шаги, на которые надо пойти, чтобы завести у себя релизы раз в неделю:

1. Строгие требования к готовностифичи.

2. Приоритет напереоткрытыхтикетах.

3. Весь функционалзакрытфичефлагами.

4. Строгое расписание релизов.

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

Пару слов о нас: мы команда банка Открытие, которая отвечает за разработку всех розничных фронтов от рабочего места сотрудника в отделении до мобильных приложений физических лиц. В последние пару лет мы переживаем взрывной рост в несколько раз у нас более 400 сотрудников ИТ и мы продолжаем расти и расти. Как оказалось, многие решения, которые были приняты на старте нашей работы, оказались верными. И о некоторых из них мы вам расскажем. Готовы? Поехали!

Один из вопросов на старте цифровой трансформации банка был таким: как нам хранить исходный код используя монорепозиторий для хранения всех миросервисов или много репозиториев? Мы выбрали такой подход: для каждого приложения, библиотеки или микросервиса создаем отдельный репозиторий.

В рамках дискуссий внутри команды для нас было очевидно, что:

• Монорепоэто решение, которое невзлетает из коробки, так как у нас банально много кода (на сегодня его около 100 GB), который просто будет долго выкачиваться к себе на локальную машину изрепозитория;

• Когда мы попытаемся открыть такой огромный проект вIDE, она скорее всего приляжет;

• При одновременной работе сотни разработчиков над одной кодовой базой потенциально ненулевые риски получитьpullrequest-ы на десятки тысяч строк кода, которые очень долго нужно будет вычитывать, чтобы понять,что вообще меняется.Которые имеют непредсказуемые срокиревью, тестирования и сложный вывод впрод;

• Оставался открытым вопрос разграничения доступа внутрирепозитория(большие компании, которыепиарилиподход смонорепонесколько лет назад,решали этокастомнымсамописом, который разграничивал доступ, например, на уровне папок);

• Очевидным плюсом было удобстворазруливаниязависимостей (в одномрепозиторииэто можноконтролировать на уровне кода). Так чтоесли отказываться отмонорепозитория, то надо было придумать как решить эту проблему.

Кирпичики, из которых складывается наше решение

• SemVer

Учитывая номер версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ, следует увеличивать:

1. МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения в работе сервиса;

2. МИНОРНУЮ версию, когда вы добавляете новую функциональность, ненарушая обратной совместимости;

3. ПАТЧ-версию, когда вы делаете какие-то внутренние исправления в работе сервиса, которые никак не меняют внешние контракты.

Дополнительные обозначения дляпредрелизныхибилд-метаданных возможны как дополнения к МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ формату.

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

• Публикация контрактов

В конвейер сборки сервисов внедрен процесс генерации и публикации контрактов, в которых однозначно описан интерфейс взаимодействия с ними. Доменные сервисы общаются с внешними потребителями наружу черезGraphQL(на самом деле у нас500+ сервисов, которые поделены на доменные группы, наподобие модной нынче и активно продвигаемойdomainorientedmicroservicearchitecture(DOMA). У каждой доменной группы есть только один внешнийGraphQLфасад, а внутри сервисы общаются поRabbitMQ, но для простоты понимания рассмотрим только пример с доменными сервисами). Сам контракт представляет из себя SDL схему, котораягенеритсяпри помощи стандартного функционала из коробкибиблиотекиqraphql-dotnetпри помощи утилитыgraphql-sdl-exporter. На самом деле утилиту мы написали сами, но решили ей поделиться и выложили еев паблик.

Что происходит после коммита:

Весь процесс контроля автоматизирован и встроен в конвейер сборки.

Шаги:

1. После коммита в любую ветку в случае, если увеличивается минорная версия, то есть у сервиса меняется интерфейс (как правило с добавлением новых элементов в контрактах), запускается процесс генерации контракта. В случае увеличения патч-версии перегенерация контракта не требуется, так как меняется только что-то под капотом без изменения внешнего поведения.

2. После из этого контракта (SDL схемы) при помощи утилит специфичных для каждого языка генерируются клиенты для различных потребителей на их языках, которые представляют собой пакеты, хранящиеся в репозитории пакетного менеджера. В нашем случае это NuGet, NPM, Graddle для .Net, JS и Java соответственно. В качестве инструмента для хранения и управления пакетов используется Arfifactory. Версия контракта (сервиса-поставщика) соответствует версии пакета. Например, сервис Payments версии 2.1.3 имеет контракт версии 2.1.0 (не 2.1.3, т.к. перегенерация для версий от 2.1.1 и выше не требуется, а потребуется только для 2.2.0).

   В тот момент, когда в Artifactory появится новая версия пакета, у разработчика, который пишет сервис-потребитель, IDE сигнализирует о том, что вышла более новая версия пакета и предложит ему обновить пакет. Увеличение минорной версии, как правило, делается не глядя (мы даже подумываем автоматизировать этот процесс), увеличение же мажорной версии говорит нам о том, что произошли обратно несовместимые изменения и требуется более осознанный подход к обновлению.

   

   Очень важный момент: Для feature веток и ветки master существуют различные хранилища пакетов: Release для master, Snapshot - для feature-веток. Причем из ветки master нет доступа к пакетам из Snapshot.

Рассмотрим пару примеров, которые продемонстрируют работу такого подхода.

Пусть сервис Accounts версии 4.7.2 потребляет сервис Payments версии 2.1.3 (обращается к нему, используя контракт в виде nuget пакета версии 2.1.0). Появилась необходимость добавить новую фичу в сервис Payments.

Вариант 1:

Допустим, что доработка сервиса Payments будет содержать обратно совместимые изменения. Тогда потребуется увеличить его минорную версию и после доработки она станет 2.2.0, что приведет к перегенерации контракта и клиентов для сервиса Payments, которые тоже станут версии 2.2.0.

Когда разработчиксервиса Payments Вася сделает коммит в свою feature ветку, увеличив версию сервиса, в хранилище Snapshot появятся новые клиенты для сервиса Payments. Разработчик сервиса Accounts Петя сможет обновить свой пакет для работы с сервисом Payments до версии 2.2.0 с новой функциональностью, сможет ей воспользоваться и реализовать свою логику работы с Payments в своей feature ветке своего репозитория.

Пока Вася доводит свой функционал до идеала, Петя допиливает свою функциональность, которая теперь зависит от версии Payments 2.2.0 и подливает свои изменения в ветку master, что в нашем случае приводит к инициации процесса релиза сервиса Accounts на прод. В процессе сборки сервис Accounts пытается разрешить свои зависимости и, в частности, получить новую версию пакета для работы с Payments 2.2.0 из хранилища Release (напомню, что master смотрит только туда), где его нет. Сборка падает с ошибкой. Автоматический контроль сработал. Петя идет к Васе, просит его побыстрее раскатать на прод новую версию сервиса Payments, после чего катит свою новую версию Accounts.

Вариант 2:

В сервисе Payments необходимо сделать обратно несовместимые изменения. Вообще мы такое категорически не приветствуем, но иногда такая необходимость возникает. Вася знает о своих потребителях (откуда скажем позже), он пишет письма ответственным и предупреждает всех о том, что собирается ломать обратную совместимость и увеличить версию своего сервиса до 3.0.0. В день Икс Вася опубликует версию Payments на тестовый контур и ждет результатов интеграционных тестов. У тех, кто не готов к обновлению сервиса Payments, попадают Beta тесты и тестовый контур станет неработоспособным в той части, которая потребляет сервис Payments. Новые контракты Payments при этом будут лежать в Snapshot. Вася не обновляет master-ветку, пока все потребители Payments не обновят свои версии пакетов для работы с Payments и не будут готовы синхроннос ним (сразу после него) раскататься на бой.

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

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

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