☕️ Как код превращается в приложение

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

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

❶ Начало работы: IDE и исходный код

Разработчики пишут код в специальных программах — IDE (Integrated Development Environment, или "интегрированная среда разработки"). Это как конструктор LEGO с подсветкой: подсказывает ошибки, помогает дописать код и сразу показывает результат.

❷ Версионный контроль: Git и ветки

Весь код хранится в системе контроля версий (VCS, например Git/SVN) — это как "хронология изменений" проекта. Самая важная ветка — master/main (основная ветка). Это эталонная, рабочая версия приложения, которая сейчас работает у пользователей.

Перед работой разработчик:
— скачивает актуальный код из мастер-ветки (как взять чистый чертёж)
— создаёт рабочую ветку (feature branch) — это как отдельная копия проекта для своих изменений. Называется обычно по смыслу: "fix-login-button" или "add-payment-feature"

❸ Пишем код и сохраняем изменения

После изменений разработчик делает коммит — сохраняет изменения с комментарием "Что я сделал и зачем". Это как сделать заметку в дневнике: "Исправил кнопку входа — теперь она не исчезает на мобильных".

❹ Проверка коллегами: Pull Request и Code Review

Когда код готов, разработчик создаёт Pull Request (PR) — это как заявка: "Мои изменения готовы, проверьте, можно ли их добавить в основной проект".

Затем коллеги проводят code review (ревью кода):
— проверяют, нет ли ошибок
— убеждаются, что код соответствует стандартам
— дают советы по улучшению

Это как если бы прораб проверил работу мастера перед сдачей объекта.

❺ Объединение: Merge в мастер

После успешного ревью изменения мержат (merge) в мастер-ветку — объединяют с основным кодом. Это как внести утверждённые правки в окончательный чертёж.

❻ Автоматическая сборка: CI/CD

Тут вступает в работу система CI/CD (Continuous Integration / Continuous Deployment):
— сборка (build): код преобразуется в исполняемый файл — как собрать модель из деталей LEGO
— тестирование: автоматические проверки, что ничего не сломалось
— деплой (deploy): размещение приложения на серверах

❼ Раскатка на "поды"

Современные приложения часто работают в системе Kubernetes — это как "диспетчер" для серверов. В ней есть поды (pods) — минимальные единицы развертывания. Каждый под — это как отдельный контейнер с вашим приложением и всем необходимым для его работы.

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

При деплое новые поды с обновлённым кодом постепенно заменяют старые — так пользователи не замечают перехода.

❽ Готовое приложение

В итоге код:
— прошёл проверку коллег
— успешно собрался
— без проблем развернулся на серверах
— доступен пользователям как рабочее приложение


🤔 Почему так много этапов?

Каждый шаг нужен, чтобы:
— избежать ошибок в продакшене (рабочей версии)
— обеспечить возможность отката, если что-то пошло не так
— дать коллегам возможность улучшить код
— автоматизировать рутину

Это как многоступенчатая система безопасности в самолёте — кажется сложной, но именно она делает полёт безопасным.

Когда в следующий раз услышите "сделал коммит" или "залил в мастер" — сможете понять на каком этапе находится фича, прежде, чем увидеть её в приложении.

#dev #ликбез #simplewords