|
|
|
@ -1,69 +1,432 @@ |
|
|
|
import type { NextPage } from 'next' |
|
|
|
import type {NextPage} from 'next' |
|
|
|
import Head from 'next/head' |
|
|
|
import Head from 'next/head' |
|
|
|
import Image from 'next/image' |
|
|
|
import Image from 'next/image' |
|
|
|
import styles from '../styles/Home.module.css' |
|
|
|
import styles from '../styles/Home.module.css' |
|
|
|
|
|
|
|
import '@fontsource/roboto/300.css'; |
|
|
|
|
|
|
|
import '@fontsource/roboto/400.css'; |
|
|
|
|
|
|
|
import '@fontsource/roboto/500.css'; |
|
|
|
|
|
|
|
import '@fontsource/roboto/700.css'; |
|
|
|
|
|
|
|
import {CopyBlock, github} from "react-code-blocks"; |
|
|
|
|
|
|
|
import {Table, TableBody, TableRow, TableCell, TableHead} from '@mui/material'; |
|
|
|
|
|
|
|
|
|
|
|
const Home: NextPage = () => { |
|
|
|
const Home: NextPage = () => { |
|
|
|
return ( |
|
|
|
return ( |
|
|
|
<div className={styles.container}> |
|
|
|
<div className={styles.container}> |
|
|
|
<Head> |
|
|
|
<Head> |
|
|
|
<title>Create Next App</title> |
|
|
|
<title>Create Next App</title> |
|
|
|
<meta name="description" content="Generated by create next app" /> |
|
|
|
<meta name="description" content="Generated by create next app"/> |
|
|
|
<link rel="icon" href="/favicon.ico" /> |
|
|
|
<link rel="icon" href="/favicon.ico"/> |
|
|
|
</Head> |
|
|
|
</Head> |
|
|
|
|
|
|
|
|
|
|
|
<main className={styles.main}> |
|
|
|
<main className={styles.main}> |
|
|
|
<h1 className={styles.title}> |
|
|
|
<h1>Trunk-Based Development</h1> |
|
|
|
Welcome to <a href="https://nextjs.org">Next.js!</a> |
|
|
|
<section> |
|
|
|
</h1> |
|
|
|
Модель ветвления в системе контроля версий, в которой разработчики работают над кодом в единственной |
|
|
|
|
|
|
|
ветке под названием ‘trunk’. Эта модель позволяет не создавать другие долгоживущие ветки и описывает |
|
|
|
|
|
|
|
технику как именно это делать. Разработчики избегают merge конфликтов при слиянии кода, не ломают |
|
|
|
|
|
|
|
сборку, и живут долго и счастливо |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>Базовые принципы</h2> |
|
|
|
|
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>Любые коммиты в trunk не должны ломать сборку</li> |
|
|
|
|
|
|
|
<li>Любые коммиты в trunk должны быть маленькими настолько, чтобы review нового кода не занимало |
|
|
|
|
|
|
|
более 10 минут |
|
|
|
|
|
|
|
</li> |
|
|
|
|
|
|
|
<li>Релиз выпускается только на основе trunk</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
|
|
<p className={styles.description}> |
|
|
|
<section> |
|
|
|
Get started by editing{' '} |
|
|
|
<h2>GIT flow VS TBD</h2> |
|
|
|
<code className={styles.code}>pages/index.tsx</code> |
|
|
|
<h3>Конфликты</h3> |
|
|
|
|
|
|
|
<Table> |
|
|
|
|
|
|
|
<TableBody> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell></TableCell> |
|
|
|
|
|
|
|
<TableCell>GIT</TableCell> |
|
|
|
|
|
|
|
<TableCell>TBD</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Auto merge</TableCell> |
|
|
|
|
|
|
|
<TableCell>Yes</TableCell> |
|
|
|
|
|
|
|
<TableCell>Yes</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Manual merge</TableCell> |
|
|
|
|
|
|
|
<TableCell>Yes</TableCell> |
|
|
|
|
|
|
|
<TableCell>Yes</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Manual merge (интеграция задачи в измененный код)</TableCell> |
|
|
|
|
|
|
|
<TableCell>Yes</TableCell> |
|
|
|
|
|
|
|
<TableCell>No</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
</TableBody> |
|
|
|
|
|
|
|
</Table> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>Долгоживущие ветки</h2> |
|
|
|
|
|
|
|
Проблемы: |
|
|
|
|
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>Накапливаются конфликты</li> |
|
|
|
|
|
|
|
<li>Код из ветки недоступен для выполнения других задач</li> |
|
|
|
|
|
|
|
<li>Параллельная разработка одного и того же механизма</li> |
|
|
|
|
|
|
|
<li>Рассинхронизация логики кода в разных ветках</li> |
|
|
|
|
|
|
|
<li>Ломается история GIT при конфликтах</li> |
|
|
|
|
|
|
|
<li>Блокируется деплой готовой задачи, если вначале нужно задеплоить другую</li> |
|
|
|
|
|
|
|
<li>Блокировка выполнения второстепенной задачи, если нужен код из другой задачи</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
<p> |
|
|
|
|
|
|
|
При GIT flow долгоживущие ветки - это норма. У нас в проекте были ветки возрастом более года. |
|
|
|
|
|
|
|
Актуализация таких веток занимала несколько дней. А ведь эти ресурсы можно было использовать на разработку новых фич! |
|
|
|
|
|
|
|
</p> |
|
|
|
|
|
|
|
<p> |
|
|
|
|
|
|
|
При TBD если разработка идет непосредственно в master/trunk таких проблем нет - код актуализируется после первого pull запроса. |
|
|
|
|
|
|
|
Разница с local state будет минимальна. В большинстве случаев получим fast forward. |
|
|
|
|
|
|
|
При работе в feature ветке могут возникать проблемы описанные выше. Чтобы минимизировать проблемы, TBD |
|
|
|
|
|
|
|
рекомендует ограничение жизнь ветки в 2 дня. |
|
|
|
|
|
|
|
Это условный интервал, за который не должно накопиться много конфликтов. |
|
|
|
|
|
|
|
Дополнительным положительным фактором является то, что основная часть команды продолжает писать в master, и этот код можно подливать в feature ветку |
|
|
|
|
|
|
|
и тем самым уменьшать количество конфликтов, которые могут появиться в день X. Когда ветка вольется в master. |
|
|
|
|
|
|
|
Важно соблюдать правило 2 дней! |
|
|
|
|
|
|
|
</p> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>Разный state БД</h2> |
|
|
|
|
|
|
|
Это порождает ошибки разработки и деплоя. |
|
|
|
|
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>Ошибка генерации миграции. Например, при добавлении новой колонки мы указываем после какой колонки надо добавить новое поле. Но этой колонки может не оказаться на момент деплоя.</li> |
|
|
|
|
|
|
|
<li>Мы не можем просто так взять и добавить колонку с constraint not null так как в других ветках код не будет работать. Это порождает тех. долг, мусорный код и ошибки, которые могут быть спровоцированы не законченным кодом.</li> |
|
|
|
|
|
|
|
<li>Ошибки doctrine. Если добавить новый тип данных doctrine, но код не распространить по всем веткам, то там где его нет, будут ошибки во время калькуляции метаданных.</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
<p>При GIT flow различное состояние бд - это норма</p> |
|
|
|
|
|
|
|
<p> |
|
|
|
|
|
|
|
При следовании TBD эти проблемы исключаются. Изменение структуры бд всегда происходит в мастер. |
|
|
|
|
|
|
|
Разработчикам остается актуализировать ветку и проблема решена. |
|
|
|
</p> |
|
|
|
</p> |
|
|
|
|
|
|
|
|
|
|
|
<div className={styles.grid}> |
|
|
|
</section> |
|
|
|
<a href="https://nextjs.org/docs" className={styles.card}> |
|
|
|
|
|
|
|
<h2>Documentation →</h2> |
|
|
|
<section> |
|
|
|
<p>Find in-depth information about Next.js features and API.</p> |
|
|
|
<h2>Разработка</h2> |
|
|
|
</a> |
|
|
|
<h3>GIT flow</h3> |
|
|
|
|
|
|
|
При GIT flow нужно работать над задачей в отдельной ветке |
|
|
|
<a href="https://nextjs.org/learn" className={styles.card}> |
|
|
|
Задач много, следовательно веток много. |
|
|
|
<h2>Learn →</h2> |
|
|
|
Все ветки различаются. Различается набор сервисов. Различается структура бд. |
|
|
|
<p>Learn about Next.js in an interactive course with quizzes!</p> |
|
|
|
Для начала разработки нужно переключиться на ветку |
|
|
|
</a> |
|
|
|
Обычно приходится почистить кеш. Применить миграции. Для тестов переинициализировать бд. |
|
|
|
|
|
|
|
Без регламента на мелкие commit`ы, провоцируются ситуации когда вся задача складывается в один commit, что делает историю менее читаемой.
|
|
|
|
<a |
|
|
|
Так же при таком подходе могут накапливаться изменения файлов при разработке. |
|
|
|
href="https://github.com/vercel/next.js/tree/canary/examples" |
|
|
|
Когда возникает необходимость переключиться на другую задачу, то нужно спрятать незакомиченные правки (при возвращении к задаче нужно будет снова накатить патч изменений). Этот процесс занимает время и отвлекает от задачи, уменьшает желание уходить с ветки. |
|
|
|
className={styles.card} |
|
|
|
|
|
|
|
> |
|
|
|
<h3>TBD</h3> |
|
|
|
<h2>Examples →</h2> |
|
|
|
При TBD нужно работать мелкими правками. Большую часть времени работаем в мастер. |
|
|
|
<p>Discover and deploy boilerplate example Next.js projects.</p> |
|
|
|
У всех приблизительно одинаковый набор сервисов, состояние БД. |
|
|
|
</a> |
|
|
|
Небольшие различия в коде, вероятно, даже не повлияют на работоспособность окружения. |
|
|
|
|
|
|
|
Если возникает необходимость переключиться на другую задачу. Нет необходимости уходить в другую ветку и пересобирать окружение. Задачу можно сделать здесь на месте. Закомитить правку и продолжить основную задачу. |
|
|
|
<a |
|
|
|
</section> |
|
|
|
href="https://vercel.com/new?utm_source=create-next-app&utm_medium=default-template&utm_campaign=create-next-app" |
|
|
|
|
|
|
|
className={styles.card} |
|
|
|
<section> |
|
|
|
> |
|
|
|
<h2>Release ready</h2> |
|
|
|
<h2>Deploy →</h2> |
|
|
|
<h3>GIT</h3> |
|
|
|
|
|
|
|
Состояние Release ready достигается путем слияния feature ветки в staging и проверке на dev стенде. |
|
|
|
|
|
|
|
По факту мы тестируем измененный код. Отличающийся от master и production. |
|
|
|
|
|
|
|
Что может спровоцировать ряд ошибок. |
|
|
|
|
|
|
|
<h3>TBD</h3> |
|
|
|
|
|
|
|
Состояние Release ready достигается за счет создания release ветки и проверке на dev стенде. |
|
|
|
|
|
|
|
Как и в случае с GIT flow. Мы создаем отдельную ветку и тестируем. |
|
|
|
|
|
|
|
Различия в том что в случае GIT на дев стенде одновременно находится ряд задач в финальной стадии реализации, нуждающиеся в мелких правках. |
|
|
|
|
|
|
|
При TBD на дев стенде будут находиться сразу все задачи принятые в работу в разных состояниях готовности. |
|
|
|
|
|
|
|
В данном случае тестируется ровно тот же код что окажется в production, с теми же feature flags. Это позволяет избежать ряда ошибок и гарантировать что эту ошибку возможно воспроизвести локально, а не искать ветку в рамках которой появилась ошибка. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Есть ряд правил которые минимизируют количество ошибок на дев стенде |
|
|
|
|
|
|
|
<ul> |
|
|
|
|
|
|
|
<li> |
|
|
|
|
|
|
|
<b>Маленькие атомарные комиты.</b> |
|
|
|
|
|
|
|
Позволяют легче воспринимать изменения и снижают риск ошибки. |
|
|
|
|
|
|
|
</li> |
|
|
|
|
|
|
|
<li> |
|
|
|
|
|
|
|
<b>Continuous review</b> |
|
|
|
|
|
|
|
Теперь код не спрятан в отдельной ветке, а доступен всем. |
|
|
|
|
|
|
|
Правки прилетают небольшие и каждый может их изучить. |
|
|
|
|
|
|
|
Тем самым будет происходить слежение за развитием продукта и понимание что меняется |
|
|
|
|
|
|
|
</li> |
|
|
|
|
|
|
|
<li> |
|
|
|
|
|
|
|
<b>Автотесты</b> |
|
|
|
|
|
|
|
</li> |
|
|
|
|
|
|
|
<li> |
|
|
|
|
|
|
|
<b>Парное программирование</b> |
|
|
|
|
|
|
|
Позволяет снизить риск, того что будет допущена ошибка и спроектировать качественное архитектурное решение по задаче |
|
|
|
|
|
|
|
</li> |
|
|
|
|
|
|
|
<li> |
|
|
|
|
|
|
|
<b>Feature flags</b> |
|
|
|
|
|
|
|
Весь не готовый код должен быть скрыт за флагом |
|
|
|
|
|
|
|
</li> |
|
|
|
|
|
|
|
<li> |
|
|
|
|
|
|
|
Сложные задачи по прежнему можно делать в отдельных ветках |
|
|
|
|
|
|
|
Важно <b>декомпозировать</b> задачу так, чтобы работы по ней длились не более 2 дней. |
|
|
|
|
|
|
|
</li> |
|
|
|
|
|
|
|
<li> |
|
|
|
|
|
|
|
<b>Частые деплои.</b> |
|
|
|
|
|
|
|
Уменьшает количество правок которое должно уйти в production. Следовательно и риски что-то поломать. |
|
|
|
|
|
|
|
</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>Схема работы по TBD</h2> |
|
|
|
|
|
|
|
<div className={styles.imageWrapper}> |
|
|
|
|
|
|
|
<Image src={`/trunk.png`} layout={`fill`}/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>TBD</h2> |
|
|
|
|
|
|
|
<Table> |
|
|
|
|
|
|
|
<TableHead> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Приемущества</TableCell> |
|
|
|
|
|
|
|
<TableCell>Недостатки</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
</TableHead> |
|
|
|
|
|
|
|
<TableBody> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Частые интеграции</TableCell> |
|
|
|
|
|
|
|
<TableCell>Сложность. Нужно понимать SOLID. Увеличивается порог входа в проект</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Постепенное изменение кода</TableCell> |
|
|
|
|
|
|
|
<TableCell>Нужно делать абстракции вокруг кода который меняется</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Возможность быстро переключиться на другую задачу</TableCell> |
|
|
|
|
|
|
|
<TableCell>Нужно написать сервисный слой для работы по TBD. Например: как использовать feature flags</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Всегда актуальный код</TableCell> |
|
|
|
|
|
|
|
<TableCell>Нужно закрывать незаконченный код через флаги, что увеличивает количество кода.</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Нет конфликтов</TableCell> |
|
|
|
|
|
|
|
<TableCell>Более качественная итоговая архитектура механизма</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Всегда одна структура бд</TableCell> |
|
|
|
|
|
|
|
<TableCell>Есть вероятность, что в проекте будут оставаться “мертвые” ветки кода.</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Уменьшение тех. долга, за счет работы с актуальной версией кода.</TableCell> |
|
|
|
|
|
|
|
<TableCell>Нужно убирать использование флагов когда код ушел в прод</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell>Нужно покрывать код тестами, легче вносить изменения.</TableCell> |
|
|
|
|
|
|
|
<TableCell>Нужно покрывать код тестами, чтобы гарантировать работоспособность.</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
<TableRow> |
|
|
|
|
|
|
|
<TableCell></TableCell> |
|
|
|
|
|
|
|
<TableCell>Чаще будем встречать push reject</TableCell> |
|
|
|
|
|
|
|
</TableRow> |
|
|
|
|
|
|
|
</TableBody> |
|
|
|
|
|
|
|
</Table> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>Branch by Abstraction</h2> |
|
|
|
|
|
|
|
Можно выделить следующие этапы: |
|
|
|
|
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>Выделить интерфейс для заменяемой функциональности.</li> |
|
|
|
|
|
|
|
<li>Заменить прямой вызов реализации в клиенте на обращение к интерфейсу.</li> |
|
|
|
|
|
|
|
<li>Создать новую реализацию, которая реализует интерфейс.</li> |
|
|
|
|
|
|
|
<li>Подменить старую реализацию на новую.</li> |
|
|
|
|
|
|
|
<li>Удалить старую реализацию.</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>Пример, реализации задачи</h2> |
|
|
|
|
|
|
|
<p>Имеем механизм отправки писем</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={`...
|
|
|
|
|
|
|
|
public function send(EmailSender $sender, array $data): void |
|
|
|
|
|
|
|
{ |
|
|
|
|
|
|
|
$sender->send($data); |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
...`}
|
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
<p>Выделяем интерфейс</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={`interface SenderInterface {
|
|
|
|
|
|
|
|
public function send(array $data): void; |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
`}
|
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
<p>Интегрируем его в старый механизм</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={`EmailSender implements SenderInterface`} |
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
<p>Заменяем прямой вызов на обращение через интерфейс</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={`public function send(SenderInterface $sender, array $data): void
|
|
|
|
|
|
|
|
{ |
|
|
|
|
|
|
|
$sender->send($data); |
|
|
|
|
|
|
|
}`}
|
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
<p>Делаем новую реализацию</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={`SmsSender implements SenderInterface`} |
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
<p>Заменяем вызов старого механизма на новый</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={` |
|
|
|
|
|
|
|
public __construct(EmailSender $emailSender, SmsSender $smsSender) { |
|
|
|
|
|
|
|
$this->emailSender = $emailSender; |
|
|
|
|
|
|
|
$this->smsSender = $smsSender; |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
public function execute() { |
|
|
|
|
|
|
|
feature(FeatureEnum::UseSmsSender) |
|
|
|
|
|
|
|
? $this->send($this->smsSender, [])
|
|
|
|
|
|
|
|
: $this->send($this->emailSender, []); |
|
|
|
|
|
|
|
}`}
|
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
<p>либо сразу через DI</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={` |
|
|
|
|
|
|
|
services: |
|
|
|
|
|
|
|
--- App\\Service\\SenderInterface: '@App\\Service\\EmailSender' |
|
|
|
|
|
|
|
+++ App\\Service\\SenderInterface: '@App\\Service\\SmsSender' |
|
|
|
|
|
|
|
`}
|
|
|
|
|
|
|
|
language={`yaml`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
<p>и в коде будет так</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={` |
|
|
|
|
|
|
|
public __construct( |
|
|
|
|
|
|
|
private EmailSender $sender |
|
|
|
|
|
|
|
) { |
|
|
|
|
|
|
|
} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
public function execute() { |
|
|
|
|
|
|
|
$this->send($this->sender, []) |
|
|
|
|
|
|
|
}`}
|
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>Feature Flags</h2> |
|
|
|
|
|
|
|
<p>Суть подхода в том чтобы обернуть код в if с проверкой пред. установленной опции. |
|
|
|
|
|
|
|
Например,</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={`if (feature(FeatureEnum::UseClickhouse)) {
|
|
|
|
|
|
|
|
// код
|
|
|
|
|
|
|
|
}`}
|
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
|
|
|
|
<p>или</p> |
|
|
|
|
|
|
|
<div className={styles.code}> |
|
|
|
|
|
|
|
<CopyBlock |
|
|
|
|
|
|
|
text={`feature(FeatureEnum::UseClickhouse)
|
|
|
|
|
|
|
|
? // новая логика
|
|
|
|
|
|
|
|
: // старая логика
|
|
|
|
|
|
|
|
`}
|
|
|
|
|
|
|
|
language={`php`} |
|
|
|
|
|
|
|
showLineNumbers={false} |
|
|
|
|
|
|
|
startingLineNumber={1} |
|
|
|
|
|
|
|
theme={github} |
|
|
|
|
|
|
|
/> |
|
|
|
|
|
|
|
</div> |
|
|
|
<p> |
|
|
|
<p> |
|
|
|
Instantly deploy your Next.js site to a public URL with Vercel. |
|
|
|
Все флаги описываются в enum, что позволяет быстро отследить все места в проекте где флаг используется. |
|
|
|
|
|
|
|
Для применения флагов на проекте, было реализовано следующее решение: |
|
|
|
</p> |
|
|
|
</p> |
|
|
|
</a> |
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>Сначала берутся значения из .env файлов</li> |
|
|
|
|
|
|
|
<li>Далее проверяются значения в переменных окружения, например: если явно передать значение в docker</li> |
|
|
|
|
|
|
|
<li>В конце проверяется значение в сессии, что позволяет быстро включить/выключить флаг и проверить функционал.</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
<p>Для удобного управления флагами и мониторинга состояния активности флага, на коленке была собрана служебная страница</p> |
|
|
|
|
|
|
|
<div className={styles.imageWrapper}> |
|
|
|
|
|
|
|
<Image src={`/feature_flags_page.png`} layout={`fill`}/> |
|
|
|
</div> |
|
|
|
</div> |
|
|
|
</main> |
|
|
|
<p>Правил с флагами будет два:</p> |
|
|
|
|
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>После того, как функциональность полностью протестирована и стабильно работает, флаг нужно удалить.</li> |
|
|
|
|
|
|
|
<li>Мест в коде, где идет ветвление по одному и тому же feature флагу, должно быть минимальное количество.</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
<section> |
|
|
|
|
|
|
|
<h2>Декомпозиция задач и Short-lived ветки </h2> |
|
|
|
|
|
|
|
Все ветки кода, кроме главной, должны иметь короткий срок жизни, максимум – несколько дней. |
|
|
|
|
|
|
|
Этого можно добиться за счет мелкой декомпозиции: ветка будет небольшой, если она решает небольшую задачу. |
|
|
|
|
|
|
|
Правильная постановка задач на этапе планирования играет очень важную роль. |
|
|
|
|
|
|
|
Можно, например, придерживаемся принципа декомпозиции задач INVEST. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Декомпозиция по INVEST определяет, каким должен быть пользовательский сценарий (user story): |
|
|
|
|
|
|
|
<ul> |
|
|
|
|
|
|
|
<li>Independent — независимый</li> |
|
|
|
|
|
|
|
<li>Negotiable — написанный понятным языком</li> |
|
|
|
|
|
|
|
<li>Valuable — несущий ценность</li> |
|
|
|
|
|
|
|
<li>Estimable — поддающийся оценке</li> |
|
|
|
|
|
|
|
<li>Small — компактный, не более 40 часов разработки</li> |
|
|
|
|
|
|
|
<li>Testable — тестируемый в широком смысле</li> |
|
|
|
|
|
|
|
</ul> |
|
|
|
|
|
|
|
Каждую из планируемых задач нужно «прогнать» по всем этим пунктам. Если по результатам выпадает хотя бы один из них, задачу нужно декомпозировать заново. |
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
</main> |
|
|
|
<footer className={styles.footer}> |
|
|
|
<footer className={styles.footer}> |
|
|
|
<a |
|
|
|
Powered by <b>Rinsvent</b> |
|
|
|
href="https://vercel.com?utm_source=create-next-app&utm_medium=default-template&utm_campaign=create-next-app" |
|
|
|
|
|
|
|
target="_blank" |
|
|
|
|
|
|
|
rel="noopener noreferrer" |
|
|
|
|
|
|
|
> |
|
|
|
|
|
|
|
Powered by{' '} |
|
|
|
|
|
|
|
<span className={styles.logo}> |
|
|
|
|
|
|
|
<Image src="/vercel.svg" alt="Vercel Logo" width={72} height={16} /> |
|
|
|
|
|
|
|
</span> |
|
|
|
|
|
|
|
</a> |
|
|
|
|
|
|
|
</footer> |
|
|
|
</footer> |
|
|
|
</div> |
|
|
|
</div> |
|
|
|
) |
|
|
|
) |
|
|
|
|
