Как организовать процесс процесс разработки одиночке?

Question

[Рамиль]

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

1. вести проект по методологиям Scrum или Agile
   
2. внедрять GitFlow
   
3. использовать практику непрерывной интеграции (CI)
   
4. деплоить проекты через Docker
   

Сейчас про эти вещи говорит каждый кому не лень. И все в одно горло кричат, что это облегчает процесс разработки.
Я пытался самостоятельно разобраться во всех этих новых технологиях и методологиях. И если по Agile и GitFlow мне все понятно, то по остальным вещам у меня возникли трудности.
В следствии, у меня возник вопрос, а нужно ли мне это, человеку который ведет разработку в одиночку?
Было бы здорово, если бы вы поделились своим опытом разработки в одиночку.

Answer 1

[Panamer]

CI да.
Больше автоматизирует нудное тестирование. Упрощает выкладку новых версий. Твоя работа будет легче, меньше ошибаться будешь.

Docker удобным образом вписывается в CI. Более того, современный софт подразумевает контейнеры для CI. Как правило это Docker.

Методологии Agilie, gitflow и пр. смысла лишены. При работе команды имеют смысл. При работе в одного - внутри своего мозга вы куда быстрее и куда лучше договоритесь.

Порядок в Git смысл имеет даже при работе в одного

P.S. gitfow и CI это противоречивые вещи.
Gitflow подразумевает выпуск кумулятивных релизов. И их поддержку (hotfix'ы).

А CI предполагает прямо противоположенное - непрерывные изменения. Без явно выраженных версий

Gitflow хорошо подходит под выпуск к примеру определенных версий Linux (ради чего и создан git), тут целесообразен полный gitfow.

В то время как например GitHub модернизирует себя постоянно и потому обходится без gitflow.
Пруф https://m.habrahabr.ru/post/189046/

Я сомневаюсь что одиночному разработчику под силу поддерживать несколько разных релизов (именно для этого нужен gitflow)

Answer 2

[Saboteur]

Методология - нет
воркфлоу и CI - да
докер - возможно

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

Comments

[Рамиль]

С методологиями понятно. А вот зачем мне CI? Ведь тесты я и сам могу запускать.

[Saboteur]

Рамиль: А зачем самому, если проще настроить сервер, который реагирует на коммит, компилит, собирает, возможно даже анализирует код каким-нить pvp-studio/sonar/veracode, деплоит, прогоняет какие-то базовые тесты, и все это делает без вашего участия - вы уже проверяете только конкретные какие-то вещи, возможно дописываете тест для них, чтобы потом не париться.

[Panamer]

Рамиль:

Ну так то вы все можете делать самостоятельно.
Но зачем?

Если рутину можно поручить автоматике CI.
Трудозатраты меньше.

Человек сосредоточен на сложных задачах, а тупизну делает автоматика.

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

Всем хорошо - качество выше, усилий меньше

[Saboteur]

Panamer: Знаете, сейчас мы спорим поскольку я говорю в общем, а вы о вашем конкретном проекте.
Если он у вас небольшой, то да, нет смысла городить вокруг него CI.

Если бы он был побольше, компиляция/сборка занимала бы час, а деплой хотя бы минут 10-20 ручной работы, вопрос о том, нужно ли автоматизировать не стоял.

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

[Panamer]

Saboteur: про CI я ничего отрицательного не говорил.

Речь только за ненужность gitflow

Answer 3

[Петр]

1. Вести проект по Scrum оправдано:
а. Вы можете выставить приоритеты своим задачам. Красивостям - маленький, тому что позволит быстрее монетизировать - большой.
б. Пользовательские истории с низким приоритетом могут быть вашим блокнотом идей.
2. Это по желанию.
Если ваш проект уже приносит деньги, то скорее нужно, так как понадобиться делать быстрые фиксы,
когда вы в данный момент разрабатываете новый функционал.
3. Это скорее для команд.

Answer 4

[Николай Бараненко]

Здравствуйте.

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

Предполагаю, что разработка в одиночку это начало, т.к. большие проекты в одиночку не утянуть и знание методологии Scrum / Agile и CI лишними не будут.

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

Comments

[Panamer]

https://m.habrahabr.ru/post/189046/
Полная методология giflow тяжеловесна даже для небольших команд.

И совершенно нерациональна для одиночки. Это просто будет распыление сил

[Panamer]

Gitflow - это выпуск кумулятивных релизов и их поддержка, то есть выпуск хотфиксов.

А CI это непрерывные изменения.

Вряд ли одиночному разработчику под силу поддерживать несколько релизов. Значит, gitflow ему не нужен.