Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-02-26

1 <p><strong>Сооснователь Хекслета Кирилл Мокевнин рассказывает, какие бывают среды разработки, как проводится контроль и испытание фичи и что такое интеграция.</strong></p>

2 <p>В любом производственном процессе, к которому относится и разработка программ, есть несколько этапов:</p>

3 <ol><li>Производство</li>

4 <li>Сборка</li>

5 <li>Контроль и испытания</li>

6 <li>Доставка</li>

7 </ol><p>Давайте рассмотрим каждый из них более подробно.</p>

8 <blockquote><p>Подписывайтесь на<a>канал Кирилла Мокевнина в Telegram</a>- чтобы узнать больше о программировании и профессиональном пути разработчика</p>

9 </blockquote><h2>Содержание</h2>

10 <ul><li><a>Производство</a></li>

11 <li><a>Сборка</a></li>

12 <li><a>Контроль и испытания</a></li>

13 <li><a>Проверка в сервере непрерывной интеграции</a></li>

14 <li><a>Доставка</a></li>

15 </ul><h2>Производство</h2>

16 <p>Открыв исходный код проекта в своем любимом редакторе, программист начинает работу. Возможно, даже пишет тесты и иногда их проводит. Если это веб-сайт, то периодически запускает сервер и смотрит в браузере, что получилось.</p>

17 <p>Место, где происходит этот процесс, называется средой разработки. Всегда есть как минимум две среды:</p>

18 <ol><li>Среда разработки, ее часто называют development environment</li>

19 <li>Среда эксплуатации, обычно ее называют production.</li>

20 </ol><p>В зависимости от среды код должен вести себя по-разному. Например:</p>

21 <ul><li>В среде разработки шире уровень логирования, то есть мы видим все отладочные сообщения, и они помогают нам разрабатывать. В продакшене этот уровень отключают, так как очень быстро "улетает" место на диске.</li>

22 <li>В среде разработки мы не можем по-настоящему слать письма. Если это произойдет, то ваши пользователи будут не рады. Кстати, это часто бывает у тех, кто не настраивает разные среды.</li>

23 <li>В среде разработки отключают кэширование - технику для ускорения доступа.</li>

24 <li>Среда разработки может содержать нерабочий код и находиться в неконсистентном (несогласованном) состоянии. Это нормально, ведь мы разрабатываем.</li>

25 </ul><p>Кроме этого, обычно код в среде разработки пишется не в основной ветке вашей системы контроля версий, а в ветке-фиче. Это важно, так как не блокирует возможность делать быстрые правки, если на сервере что-то сломалось, и нужно поправить только небольшой кусок, а новые наработки вы еще не готовы выливать.</p>

26 <h2>Сборка</h2>

27 - <p>После того как вы реализовали свою задачу (фичу) и она была протестирована, ее код вливается в основную ветку. Возможно, параллельно с разработкой вашей фичи еще один разработчик программировал вторую в другой ветке. Теперь в основной ветке они встретились - это называется интеграция. А работают они вместе или нет - еще предстоит выяснить. Этот пункт сильно зависит от того, какой процесс выбран в конкретной команде.</p>

27 + <p>После того как вы реализовали свою задачу (фичу) и она была протестирована, ее код вливается в основную ветку. Возможно, параллельно с разработкой вашей фичи еще один разработчик программировал вторую в другой ветке. Теперь в основной ветке они встретились - это называется интеграция. А работают они вместе или нет - еще предстоит выяснить. Этот пункт сильно зависит от того, какой про��есс выбран в конкретной команде.</p>

28 <h2>Контроль и испытания</h2>

29 <p>Обычно тестирование включает в себя несколько этапов. Первый, на котором происходит проверка конкретно вашей отдельной фичи, и второй, когда проверяется все, что пойдет в следующий релиз.</p>

30 <p>Ведь даже собрав все фичи в одну ветку и проверив их локально, нельзя быть до конца уверенным, что в реальных условиях все будет хорошо работать. Кроме того, скорее всего, у вас есть менеджер или даже тестировщики, которые тоже хотят посмотреть и проверить, все ли хорошо. Тут появляется еще одна производственная среда, которая называется средой интеграции (препродакшн) или стейджинг (staging), как ее все называют.</p>

31 <p>Стейджинг - это такая среда, в которой происходит проверка перед деплоем в продакшен. Она максимально приближает к условиям рабочей среды, что дает возможность полнее протестировать то, что происходит. Обычно это то место, куда идут менеджеры, тестировщики, заказчики. Часто стейджинг выполняет сразу две задачи - проверку конкретных фич от разработчиков и окончательный прогон приложения перед релизом.</p>

32 <p>Тут появляется еще одно новое слово - релиз, или по-другому выпуск. С одной стороны, это процесс выкатки в продакшен новой версии системы. С другой стороны, так иногда называют сборку, которая представляет из себя новую версию системы.</p>

33 <h2>Проверка в сервере непрерывной интеграции</h2>

34 <p>Одна из разновидностей сборочной среды называется сервером непрерывной интеграции (Continuous Integration Server). Это такая отдельная машина, а может и целый парк машин, на которую выливается код для проверки в автоматическом режиме.</p>

35 <p>Обычно это происходит по какому-нибудь событию, например, на GitHub это пулл-реквест. В настроенных проектах каждый пулл-реквест отправляется в сервис, подобный встроенному в GitHub<a>Github Actions</a>. Этот сервис прогоняет тестовый набор на нужной ветке с фичей и после этого прикрепляет отчет к пулл-реквесту, в котором пишет о результатах проверки.</p>

36 <p>Такая система позволяет очень сильно ускорить процесс интеграции. Сильно снижается нагрузка на разработчиков и автоматизируется рутина. Разработчику достаточно писать код и отправлять его в репозиторий, а система сама будет проводить необходимые проверки и выполнять слияние. Непрерывная интеграция является частью практик под названием "экстремальное программирование (XP)".</p>

37 <h2>Доставка</h2>

38 <p>После того, как вы закончили разработку, код попадает в препродакшн и продакшен-среду. Это происходит благодаря процессу, который в простонародье называют "деплой".</p>

39 <p>Как показывает практика, многие до сих пор делают деплой руками. Заходят на сервер, клонируют код, руками меняют базу и так далее.</p>

40 <p>Можно бесконечно обсуждать то, насколько это плохо. Начиная с отсутствия налаженного повторяемого процесса, в котором есть вероятность, что кто-то из участников что-то забудет, потеряет или удалит. Заканчивая тем, что знания хранятся в одной голове, и сам процесс релиза становится вуду-процедурой, которую может делать только Вася. А иногда он болеет, ходит в отпуск или вообще однажды может уволиться. Часто в таких компаниях релиз - крайне болезненная процедура, которая занимает не один час, а может даже пару дней.</p>

41 <p>При хорошо отлаженном процессе релиз занимает десяток минут, и может делаться любым разработчиком почти в любой момент. Хекслет иногда деплоится по 5-10 раз в день.</p>

42 <p>Основные задачи, которые стоят перед вами во время деплоя:</p>

43 <ul><li>Взять новую версию кода из репозитория и залить его на сервер</li>

44 <li>Сделать все необходимые приготовления: накатить миграции, собрать фронтенд-скрипты</li>

45 <li>Переключить проект на новую версию</li>

46 <li>Откатиться в случае ошибок.</li>

47 </ul><p>В среднем проекте количество действий, которые необходимо сделать при деплое, уже составляет десятки различных задач. Хорошая новость в том, что в современном мире это настолько отработанная процедура, что существует немало решений, позволяющих настроить деплой любого проекта. Одним из таких решений является<a>набор скриптов поверх Ansible</a>.</p>