Часто разработчики-одиночки не пользуются привычными инструментами и практиками вроде VCS, CI/CD, которые используют в командах. Спросили у экспертов, правильно ли они делают и как можно самому построить процесс разработки, сопровождения и деплоя. Константин Коногорский заместитель директора по разработке «ВИСТ» (группа «Цифра») рассказывает как это работает.
Каждый случай индивидуален. Все зависит от объема работ, процесса согласования результатов, сроков поддержки, модернизации и многих других факторов. Зачастую кажется, что все эти системы контроля версий только увеличивают время на разработку.
Например, когда проект небольшой и есть четкое ТЗ, подробно покрывающее потребность заказчика и выполнимое в конкретный отведенный срок без возможности дальнейшей модернизации все эти дополнительные сложности могут быть и не нужны. Написал на локале, показал заказчику, сдал проект и доволен. Но даже в таком случае системы контроля версий не будут лишними. Они могут застраховать разработчика от нечаянного удаления проекта или возврата к коду, который ранее казался неправильным (откат к прошлой версии). Но опять же если мы пишем калькулятор, то это не нужно.
Но такие проекты существуют только в идеальном сферическом мире, в вакууме. Чаще всего заказчик сам не знает, что конкретно ему нужно. После выполнения проекта по ТЗ фантазия заказчика только начинает разыгрываться, и он просит добавить в свой продукт все больше и больше фич.
В этих ситуациях без системы контроля версий не обойтись. Она позволит сократить время на согласование, так как можно накидать прототипов разных интерфейсов в разных ветках, не внося больших правок в продакшн код. Показать их заказчику, скорректировать (повторять до полного удовлетворения заказчика) и только после этого мерджить в прод. Причем работать можно параллельно над несколькими фичами, так как устраивать демонстрацию каждой отдельной фичи очень накладно по времени, а время заказчика надо уважать.
Для более крупных проектов контроль версий просто необходим, даже если разработчик всего один. Так как заказчик, с которым программист очень приятно и продуктивно поработал год назад, может вернуться и предложить новое сотрудничество. А с тех пор ноутбук мог умереть, у заказчика мог умереть сервер и вообще «метеорит упал на Челябинск». Нынешние бесплатные системы контроля версий облачные и вероятность потерять с них данные достаточно мала следовательно даже через год можно вернуться к внесению новых фич к старому софту.
Что касается CI\CD его необходимость также индивидуальна для каждого проекта. Этот инструмент очень сократит время при непрерывной разработке (когда с первого прототипа и до конечного варианта софт уже используется заказчиком). Все опять же зависит от объема. Если это калькулятор и его используют 1 раз в день можно остановить работу своего приложения и на флешке поставить новую версию. Но когда софт большой, состоит из множества модулей и нагрузка на него непрерывна, то процесс обновления может занять значительное время. В этом случае даже соло программисту стоит задуматься об автоматизации этого процесса (включая тестирование, дабы не выкатить случайно код, который все положит).
