Я думаю, в любой айтишной компании, где разрабатывают программное обеспечение так или иначе используют какие-то средства автоматизации процесса разработки, ведь надо же как-то ставить задачи и отслеживать их сроки выполнения, регистрировать и исправлять ошибки, делать сборки и еще много всего прочего. Средств для достижения тех или иных задач много, но, к сожалению, нет одного универсального, в котором было бы все и сразу. В попытках найти для себя наиболее оптимальный набор таких средств, решил написать вот такой пост, собрав в нем сведения о продуктах, которые я знаю. Но, вдруг, найдутся читатели, которые дополнят этот список или же как-то выскажут как и что используют они сами.
Для начала попробую сформулировать список задач, которые необходимо эффективно решать:
- Контроль версий
- Гибкая и удобная настройка прав доступа к репозиториям
- Код-ревью
- CI, автотесты, отчеты
- Баг-трекер
- Вики, проектная документация
- Постановка задач, таск-менеджер
В идеале, конечно, хочется получить некую единую инфраструктуру, в которой процесс разработки протекал бы следующим образом:
- Менеджеры, архитекторы ставят задачи по разработке нового функционала со сроками и с возможностью указания приоритетов, в какой последовательности надо решать задачи.
- По каждой задаче есть конкретный ответственный программист, который или сам начинает решать задачи, или, если задача комплексная, разбивает ее на более мелкие и раздает подчиненным программистам.
- Программисты начинают решать поставленные задачи в отдельных ветках системы контроля версий, периодически запушивая свои наработки в репозитории.
- Перед сливанием нового функционала в основную dev-ветку, код должен пройти ревью кем-то из коллег. И только после одобрения и исправления замечаний ветка сливается в основную. То же самое относится и к багфиксам.
- При запушивании кода в репозиторий, в идеале, код проверяется на соответствие утвержденным стандартам, наличию *doc комментариев ко всем написанным/переписанным классам/методам/свойствам, дабы свести процесс код-ревью к выявлению логических и структурных ошибок, не тратя время на синтаксис и проверку комментариев.
- К коду пишутся хотя бы минимальные юнит-тесты, которые так же хранятся в репозитариях и которые автоматически прогоняются CI-сервером при появлении в репозиториях проектов нового кода.
- Периодически происходят сборки проектов и отдаются тестировщикам, которые находят там ошибки, регистрируют их в баг-трекере. Эта информация автоматически попадает к ответственным разработчикам. Разработчики исправляют ошибки, они автоматически закрываются в трекере, оповещая тестировщиков. После чего, в рамках следующей сборки, тестировщики убеждаются в том, что ошибки и вправду были исправлены и подтверждают закрытие ошибок или же заново открывают ошибки для исправления.
- Так же программисты описывают свои решения того или иного функционала в вики, чтобы любой член команды мог не дергая коллег ознакомиться и понять как устроен и работает тот или иной компонент, функционал проекта. Желательно чтобы была возможность указания на точные файлы, а может и даже строки в файлах проекта.
- При появлении нового участника проекта, хорошо бы иметь легкую и удобную возможность настройки прав доступа этого участника к коду: кому можно коммитить в master/dev-ветки, кому запретить push force и т.д.
- При выполнении поставленных задача программисты отмечают это в такс-менеджере. Если задача выполнена раньше, это автоматически сдвигает начала выполения последующих задач вперед. Если задача просрочена, это автоматически отодвигает последующие задачи, отмечая их как уже не укладывающиеся в запланированные сроки.
Ну, как-то так. Может чего и забыл, но общая идея ясна.
Давайте теперь попробуем посмотреть все по пунктам и то, что есть для решения этих задач.