Перейти к содержимому

12.08.2013

2

В поисках оптимальных средств сопровождения разработки. Введение.

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

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

  1. Контроль версий
  2. Гибкая и удобная настройка прав доступа к репозиториям
  3. Код-ревью
  4. CI, автотесты, отчеты
  5. Баг-трекер
  6. Вики, проектная документация
  7. Постановка задач, таск-менеджер

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

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

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

  • frost

    Спасибо вам за отличные статьи)
    Будет ли продолжение?

    • KSDaemon

      Непременно будет! 😉