Trunk Based Development: техники и определения

Давайте разберем термины из предыдущего поста

Branch By Abstraction — пожалуй, краеугольный камень TBD. Попробуем объяснить эту технику на единорожках. У нас есть обычная лошадка 🐴, но мы понимаем, что вообще-то нам нужен единорог. 🦄

Справка: единороги отличаются от лошадей рогом, магией и тем, что их тошнит радугой. При этом магия без рога не работает.

Соотвественно, нам нужно добавить к нашей лошадке три фичи, чтобы получился единорожек.

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

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

Чтобы обезопасить себя и скрыть от пользователя, что с его поняшкой что-то происходит, можно использовать Feature Toggles — механизм управления фича флагами. Этот именно тот переключатель, который выбирает нужную логическую ветку и включает у пони режим единорога.
Есть готовые решения, такие как LaunchDarkly или Unleash, но можно при желании реализовать их самостоятельно.

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

После контроля качества нового функционала, можно открыть его бета-тестерам, а потом какому-нибудь проценту пользователей, чтобы изучить их реакцию. Можно поэкспериментировать с формой рожек, чтобы понять, какой из них больше нравится (AB тесты в таком подходе работают из коробки). Так как передеплоивать ничего не нужно, наша лошадка всегда может вернуться в предыдущее состояние, просто поменяв конфигурацию.
В этот период у нас получается единорог Шредингера: он и есть и нет, все это управляется конфигурацией. Определение релиза фичи при этом тоже меняется — это момент, когда 100% пользователей получат своего единорожка. 🦄

Каждое эволюционное изменение должно быть небольшим по объему и делаться в короткоживущей ветке (Short Living Feature Branch). Такая ветка живет от силы пару дней, быстро ревьюится и объединяется с основной. Кодревью при этом быстр и несложен из-за небольшого объема изменений.

Любое изменение кода сразу же эволюционирует нашу лошадку (раскатывается на продакшн). Такой подход называется Continuos Deployment, не путать с Continuous Delivery, когда мы просто собираем артефакт, но нигде его не устанавливаем. Страшно?

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

#rdclr_backend #rdclr_frontend #product

Сколько нужно стендов/энвайроментов в Trunk Based Development подходе

Вы решили попробовать TBD и придумали классную многокомпонентную архитектуру для вашего единорожка. Сколько вам нужно окружений, чтобы все работало как нужно?

🦄 Если у вас возник вопрос, при чем здесь единороги, смотрите предыдущий пост.

В зависимости от вашей философии разработки и готовности экспериментировать, правильным ответом может быть 2️⃣, 3️⃣ или 4️⃣.
Давайте рассмотрим каждый из них.

Но начнем с 1️⃣. Single Environment — вполне себе жизнеспособный подход. В Trunk Based Development основная ветка считается стабильной, новый функционал скрыт фича тогглами, поэтому ничего не мешает жить с одним окружением. При условии, если архитектура вашей системы позволяет гарантировать стабильность транк-веток репозиториев всех компонентов без интеграционных тестов между этими компонентами и без инструментов типа Terraform или Helm для управления инфраструктурой. Ну или у вас огромное количество времени и вычислительных можностей и внутри CI/CD пайплайна вы каждый раз поднимаете мини-энв. Поэтому от сферических единорожков перейдем к реальным. 🌈

2️⃣ окружения. Итак, нам нужно иметь возможность проверять изменения кода до того, как они попали в основную ветку. Очень простой рецепт — вешаем CI триггер на пуллреквесты.
Алгоритм следующий: разработчик создает свою короткоживущую веточку, делает изменения, тестирует их локально. Потом пушит и делает пуллреквест в основную. CI собирает компонент, делает статический анализ (линтер или SonarQube), прогоняет юнит тесты, упаковывает в докер и разворачивает на отдельном стенде (обычно мы называем этот стенд dev или sandbox, давайте и будем называть его песочницей). Тут же в пайплайне запускаются автотесты (для бэкенда достаточно API тестов, для фронтенда тестов в headless браузере). При этом на любом шаге, если что-то сломалось, пайплайн не завершится и песочнца будет сломана. Но откатиться до предыдущего состояния можно, просто сделав реверс пуллреквест.
Если все прошло успешно, это означает, что новые изменения не ломают предыдущей логики, зафиксированной тестами. Разработчик может протестировать новый функционал на стенде, и после этого отправить пуллреквест на ревью.
То есть на ревью попадает пуллреквест, который заведомо ничего не сломает. Поэтому ревьюеры могут сконцентрироваться на проверке бизнес-функционала, а не на отлове возможных несовместимостей. После ревью изменения мерджатся в основную ветку и проходят все те же шаги сборки и регрессии, но уже на втором, боевом стенде. С каждым изменением единорожек эволюционирует.

У предыдущего подхода есть минус. Он защищает нас от того, что сломается автоматизация инфраструктуры и бизнес логика. Но не защитит от некорректных данных в БД, а это иногда становится большой проблемой. В варианте с двумя окружениями второй, стабильный энв содержит и тестовые и продакшн данные. Чтобы физически изолировать их, можно добавить третий стенд. 3️⃣
Итак, первый стенд — sandbox, разработчики могут его ломать и экспериментировать еще до ревью
Второй — test, он содержит код, собранный из основных веток, но он предназначен только для тестирования нового функционала. Теоретически на нем можно сломать данные, тестируя какие-нибудь негативные сценарии (А что будет, если напоить единорога самогоном вместо утренней росы? 🤮)
Третий — prod, и там разворачиваются те же самые артефакты, что были собраны на предыдущем шаге. При этом хорошей практикой считается раскатывать сюда новую версию сервиса, как только она прошла авторегрессию на тесте. Мы все еще находимся в парадигме Continuous Deployment и Shift Right (см предыдущий пост), но тестовое окружение физически отделено от продакшена.

Какой подход вам нравится больше всего?
#rdclr_backend #rdclr_frontend #product

Отдельно рассмотрим вариант с 4️⃣ стендами.

Он может применяться, когда по внутренним регламентам или соображениям безопастности мы сознательно отказываемся от Continuous Deployment на прод. Мы изобрели этот гибридный подход, чтобы оставить нашему единорожку возможность бесшовно эволюционировать
🐴🔜🦄 и, в то же время, иметь возможность выпускать его на волю дискретными релизами.

Какая проблема возникает при отказе от Continuous Deployment? То, что нам приходится где-то замораживать версию продукта для стабилизации, но при этом мы не хотим останавливать разработку нового функционала. Поэтому можно использовать следующий поход:
sandbox и test остаются как и в предыдущем варианте — это инкубатор, где единорог постепенно эволюционирует.

Как только мы понимаем, что он достаточно хорош, нам приходится его клонировать, отсаживая в отдельный загончик — релизную ветку. Оттуда собираются артефакты на третий промежуточный стенд — stage. На нем происходит стабилизация, после чего единорожка выпускается на волю (на prod), а релизная ветка со всеми багфиксами тэгается, мерджится обратно в транк и закрывается. При этом основную ветку ничто не останавливает и она уходит вперед.

🐛 Если находится критический баг на продакшене, мы можем выпустить патч-релиз. Для этого мы просто восстанавливаем релизную ветку нужного сервиса из тэга и используем stage для новых изменений в нашем загончике, после чего он снова попадает на prod, а изменения тэгаются, мержатся в основную ветку, а патч-ветка закрывается.

При таком подходе мы все еще остаемся в парадигме Trunk Based Development, т.к. у нас
- одна основная ветка (trunk), 🦋
- короткоживущие фича ветки для эволюции (slfb),
- релизные ветки, которые живут только в период стабилизации,
- стабилизационные багфикс ветки, которые живут еще меньше, чем релизная

#rdclr_backend #rdclr_frontend #product

Ревью кода: кросс-ревью. Практики тим-лидов

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

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

Однако, мое мнение, что все вышеперечисленное абсолютно неверно и на всех своих проектах стараюсь вводить такую практику как кросс-ревью.

🦀 Кросс-ревью — это проверка кода всеми членами команды.

А теперь как в Турецком сериале: «Самое интересное в следующей серии» 😉

#teamlead #rdclr_backend #rdclr_frontend

Вы подумали это все? А вот и нет =)
👍🏻 При кросс-ревью нет нагрузки на отдельного разработчика (тим-лида), который один должен пересмотреть все ревью.

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

🚨 На такой случай есть суперский лайфхак: будучи тимлидом или ведущим разработчиком, вы можете специально допустить несколько ошибок в ревью, дабы проверить, кто добросовестно просматривает ваш код.

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

📮 В ходе повествования я упирался в слово «код», но такая практика может быть использована в команде абсолютно любого направления. И важно добавить, что под словом «команда» подразумевается отдельное направление (бэк, фронт, qa, дизайн и тд).

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

Надеюсь, у всех вас на проектах существует кросс-ревью и вы ему рады. 😀
#teamlead #rdclr_frontend #rdclr_backend

Что такое нейронные сети

Хотелось бы начать с краткого экскурса в нейронные сети. Открыв любой интернет источник, можно очень часто увидеть такую формулировку: «Искусственные нейронные сети — это вычислительные модели, вдохновленные человеческим мозгом».

🧠 Нейронные сети действительно напоминают мозг человека (животного), как минимум следующими признаками:
1) нейронная сеть получает знания посредством обучения;
2) знания нейронной сети — это хранилище сил межнейронных связей, также известных, как веса нейронной сети.

Любые алгоритмы разрабатываются с целью решения каких-то задач, нейронные сети не стали исключением. Они позволяют выполнять задачи по осмыслению данных, сохраняя при этом свои другие свойства.
Сейчас мы их разберем.
#rdclr_backend #NN

Нейронные сети и их задачи. 1 — Классификация
Разберем подробнее каждый из типов задач.

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

Одна из самых первых задач, с которой сталкивается человек, который только начал изучать нейронные сети — это определение того, что представлено на изображении: кошка или собака.🐕🐈‍⬛
Это накладывает определенные ограничения на обучающую выборку, так как каждый набор данных должен быть помечен. Пример задачи с кошками и собаками говорит, что абсолютно к каждому изображению должно быть пояснение. А именно, к какому классу относится данное изображение (кошка или собака).

Подход, когда заранее известны выходные данные нейронной сети, называется «контролируемое обучение», или «обучение с учителем».
#rdclr_backend #NN

Нейронные сети и их задачи. 2 и 3 — Кластеризация и Предиктивный анализ

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

🧐 Например, это может быть сравнение изображений или звуков, а также обнаружение аномалий. Для кластеризации крайне необходимо иметь большую выборку, ибо чем больше данных «прогонит» через себя нейронная сеть, тем точнее она будет.

💎 Предиктивный анализ
Предиктивный анализ по-другому часто называют задачей регрессии.

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

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

Дальше мы разберем популярные библиотеки и инструменты работы с нейтронными сетями. А пока — хорошего вечера! 🥟
#rdclr_backend #NN

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

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

🌪 jupyter notebook — это мощный инструмент для разработки и представления data science проектов. Он способен хранить код, графики, изображения и формулы в одном месте.

💨 google colab — бесплатная облачная среда от компании Google, позволяющая работать с jupiter блокнотами. Данный сервис предоставляет 12 ГБ ОЗУ и сессии до 12 часов. Так же, как и у остальных продуктов данной компании, реализована возможность совместного использования.

#rdclr_backend #NN

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

1. 🍏 TensorFlow — платформа с открытым исходным кодом, разработанная компанией Google для создания приложений глубокого обучения. Он также поддерживает традиционное машинное обучение.

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

2. 🍎 PyTorch — это библиотека машинного обучения, разработанная командой Facebook AI Reseach. Полностью основана на python и использующая мощность графических процессоров. Это также одна из предпочтительных исследовательских платформ глубокого обучения, созданная для обеспечения максимальной гибкости и скорости.

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

3. 🍐 Keras — это высокоуровневый API глубокого обучения. Keras относительно прост в освоении, так как предоставляет интерфейсы с высоким уровнем абстракции. Именно эту библиотеку рекомендуется начать изучать людям, которые только начинают освоение нейронных сетей.

P.S. В конце хотелось бы порекомендовать сайт, который будет полезен студентам и людям, работающим с нейронными сетями. Он позволяет строить базовые схемы нейронных сетей — alexlenail.me 🧩

#rdclr_backend #NN

Нейронные сети: принцип трансферного обучения
Одной из причин такого результата работы нейронной сети было то, что ей «не хватало» знаний о том, что изображено на конкретной картинке. Для того, чтобы исправить данную ситуацию, необходимо использовать уже готовое решение.

Transfer learning
♻️ Трансферное обучение — это повторное использование существующих моделей для решение новой задачи или проблемы.

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

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

🌗 Возвращаясь к задаче раскраски черно-белых изображений, одним из решений было использование предобученной нейронной сети для классификации изображений и объединение выхода данной нейронной сети с собственной нейронной сетью на определенном этапе ее работы. Это и позволило получать более приемлемые результаты.
#rdclr_backend #NN

Микросервсиная архитекутера

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

Можно взять и разбить приложение на микросервисы. Но это не даст гарантий, что проект будет легко поддерживать и масшабировать, гибко изменять код — рано или поздно вы столкнетесь с проблемами. Для решения таких проблем как раз и появились различные принципы программирования — SOLID, DRY, KISS, CQRS.

#rdclr_backend #Java

Друзья, привет! На связи всё так же я, Павел, Java-разработчик Red Collar. 🤝

Решил потестить новый формат, чтобы текст легче воспринимался, а иллюстрации кода не терялись потом в поиске.

В общем, встречайте первую статью в Telegraph! Собрал здесь все принципы SOLID с примерами, подсветил сложные моменты, про всё рассказал подробно. 🦾

Читайте тут: https://telegra.ph/Open-closed--princip-otkrytosti--zakrytosti-05-16


#rdclr_backend #Java

Друзья, всем привет! Это вновь я, Java-разработчик Red Collar Павел.
Продолжаю тестить Телеграф и рассказывать вам о фишках разработки. На этот раз — о Spring DATA JDBC.

Это классная альтернатива JPA, но у неё, конечно, есть свои подводные камни.

Читайте о них здесь: https://telegra.ph/Spring-DATA-JDBC-05-24

#rdclr_backend #Java