Как разработчику-одиночке правильно построить процесс создания и деплоя ПО — отвечают эксперты

Разработчик-одиночка в общем случае мало чем отличается от команды разработчиков с точки зрения построения собственных процессов. В случае с одним человеком, который работает над каким-то продуктом, такой разработчик одновременно берёт на себя все обязанности по работе над продуктом в виде полного цикла «заботы» о нём:

• планирование и дизайн продукта, разметка целевой аудитории;
• написание первичной версии приложения;
• тестирование первичной версии самостоятельно или с помощью приятелей и друзей;
• вторичная — «релизная» — версия приложения, исправленная с учётом тестирования первичной версии;
• финальное тестирование;
• релиз ПО ограниченному кругу пользователей для сбора дальнейшего фидбека;
• дальнейшее изменение продукта в соответствии с нуждами пользователей и вечный цикл поддержки продукта после его финального релиза.

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

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

1. Обязательно использовать VCS (например, приватный репозиторий на GitHub) – поможет следить за версиями продукта, понимать разницу между предыдущим и следующим релизом, а также даёт возможность разделять стабильные релизы от нестабильного кода, над которым в данный момент ведётся работа.
2. Присваивать версии по системе Semantical Versioning — позволит выработать дисциплину относительно размера изменений в продукте. Значительные изменения выпускаются гораздо реже (особенно, если проект поддерживается одним человеком), чем небольшие правки маленьких ошибок.
3. Важно самому тестировать собственный продукт после добавления определённого количества возможностей в продукт. Либо попросить знакомых сделать это вместе с вами, чтобы получить больше сторонних мнений (не принципиально, что такие тестеры не являются целевой аудиторией — главное не UI/UX фидбек, а механическое тестирование функций).
4. Придётся самостоятельно общаться с пользователями проекта. Это может быть почтовое общение через почту поддержки, а может быть и через специальную площадку для фидбека о продукте. Главное — определиться с максимальным временем ответа, чтобы пользователи не ждали долгого ответа и знали, что им ответят в течение, например, 72 часов.
5. Если разработчик, работающий над проектом один, не пользуется средствами трекинга задач для своего продукта, то ему могут помочь простые маркеры TODO и FIXME в собственном коде. Современные редакторы (например, VSCode) позволяют анализировать код и создавать деревья TODO и FIXME, с помощью которых можно отслеживать всё, что хотелось бы рано или поздно реализовать или изменить в продукте. Такие маркеры — это часть натуральной документации кода, которая позволит одиночке не забыть о том, в какую сторону движется код.
6. В CI/CD нет необходимости, если работаешь один (по крайней мере до первого релиза точно). Некоторые процессы можно автоматизировать, но это далеко не обязательно делать с помощью тяжеловесных облачных сервисов CI/CD — автоматизацию можно выполнить в виде ряда скриптов, которые будут брать на себя основную тяжёлую рутинную работу. К тому же, локальные скрипты автоматизации — это бесплатно.

В наши дни я не могу представить себе процесс написания кода без Git. Даже если работаю один над пет-проектом.

Во-первых, я всегда знаю какие файлы я редактировал и что именно я в них менял. Это позволяет править код без страха, и гораздо легче находить причины неработоспособности кода. Любые изменения видно после долгого перерыва работы над проектом и даже после перезагрузки компьютера. Что невозможно при использовании ctrl + z.

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

Также, без системы контроля версий невозможно реализовать деплой сайта или приложения. Только если написать скрипт, который будет полностью перезаливать все файлы на сервер по FTP или SSH. Но такой процесс будет долгим и сложным – в любой момент соединение может оборваться и придётся делать всё заново. А с наличием Git, можно как минимум подключиться к серверу и сделать git pull. Когда-то мы даже использовали такой подход в продакшене.

Однако, это было до того, как веб-приложения стали нуждаться в установке зависимостей и сборке. Но и сейчас можно достаточно легко написать скрипт, например на bash, который будет клонировать новую версию проекта в отдельную папку, делать npm install, npm run build и менять символическую ссылку. А в случае проблем, запускать скрипт переключения символической ссылки на папку с предыдущей версией. Деплой на коленке готов.

Во избежание проблем с самописными решениями, я могу посоветовать воспользоваться утилитой Ansistrano. Она делает всё, что описано выше и при этом заходить на сервер не обязательно. Можно запустить скрипт прямо со своей машине. А сценарии деплоя и отката описываются в декларативных yml-файлах. Плюс, все действия идемпотенты и есть гибкие настройки: ветка, тег, коммит с которых производить деплой, количество сохраняемы резервных копий и так далее.

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

Если пойти чуть дальше, то можно освоить базовые функции Bitbucket Pipelines или GitHub Actions. Скрипты у них тоже пишутся в yml-файлах, только синтаксис везде разный. Но плюсом получаешь заготовленные сценарии, которые, например умеет использовать кеши npm, что значительно ускоряют процесс, и много других фич. Так же можно организовать автоматический деплой по мерджу в master или добавлению тэга. И это уже будут настоящие CI/CD.

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

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

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

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

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

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

Что касается CI\CD – его необходимость также индивидуальна для каждого проекта. Этот инструмент очень сократит время при непрерывной разработке (когда с первого прототипа и до конечного варианта софт уже используется заказчиком). Все опять же зависит от объема. Если это калькулятор и его используют 1 раз в день – можно остановить работу своего приложения и на флешке поставить новую версию. Но когда софт большой, состоит из множества модулей и нагрузка на него непрерывна, то процесс обновления может занять значительное время. В этом случае даже соло программисту стоит задуматься об автоматизации этого процесса (включая тестирование, дабы не выкатить случайно код, который все положит).

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

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

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

Системы CI\CD также обязательны к применению, важно лишь правильно автоматизировать выполнение наиболее частых и повторяющихся действий и в целом изначально закладывать возможности для полной автоматизации сборки и публикации артефактов проекта.

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

Исключительно полезно настраивать развёртывание проектов через такие платформы как GitLab и TeamCity. Их использование бесплатно для небольших команд, а доступного функционала более чем достаточно для малых и средних проектов. Это позволит соблюдать верный баланс между поиском решений для частных проблем автоматизации, которые присутствуют в каждом проекте и оптимальным использованием ресурсов современных платформ.

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