Курс «Организационные аспекты совместной разработки»

Аннотация

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

План курса

• Введение.
  • Зачем этот курс

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

  • Структура курса, почему так

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

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

• VCS
  • Зачем VCS
  • Use cases и вытекающие из этого свойства

    • см. http://hades.name/blog/2009/05/23/the-git-parable-ru/

  • DVCS
  • Workflow при использовании DVCS
  • Git как пример (D)VCS

    • http://hades.name/blog/tag/git/

  • Управление репозиториями

    • http://hades.name/blog/2010/09/07/your-own-git-hosting-prologue/

    • http://hades.name/blog/2010/12/02/your-own-git-hosting-gitolite/

  • Практика: развёртывание gitolite

• Сервисы, лежащие в основе взаимодействия: HTTP, SMTP, SSH

  • В принципе, при наличии достаточно удобной VCS (например, git или hg), на ней при должном желании можно и остановиться — всё необходимое для совместной работы с кодом там есть. Но в реальной жизни это верно далеко не всегда: людям так или иначе необходимо общаться, есть вещи, которые по какие-то причине не лежат в репозитории, а знать про них надо, коммиты сами тоже далеко не всегда идеальны и некоторые из них нужно обсуждать, код, кроме того, чтобы быть, ещё должен как-то собираться, тестироваться и запаковываться, иногда для работы с кодом требуются различные (экзотические) окружения. Всё это, опять же, при должном желании можно делать через VCS же с соответствующим количеством костылей^Wхуков, ко иногда эти задачи удобнее решать при помощи других инструментов. Им и посвящена оставшаяся часть курса.

  • Роль web-сервисов в процессе взаимодействия
  • Связка httpd2+mod_wsgi+python как пример платформы для развёртывания веб-сервисов
    • Аутентификация: HTTPS, клиентские сертификаты
    • VCS, поддерживающие работу череp HTTP (svn, что ещё?)
  • Почта как основа системы оповещения и информационного обмена в рамках совместной разработки
    • Культура использования почтовых рассылок для информационного взаимодействия
    • Использование почты в рамках VCS (git-send-email/git-am)
    • Альтернативные способы оповещения — XMPP, VoIP-конференции, связь с почтой (?)
  • mailman как пример системы для организации списка рассылок
  • Удалённый доступ как инструмент совместной разработки — предоставление окружения

  • Практика: развёртывание и настройка httpd2 (mod_wsgi, аутентификация)

  • Практика: развёртывание и настройка mailman

• Аутентификация
  • Зачем аутентификация
  • Где нужна аутентификация

  • Способы аутентификации (HTTP-only — htdigest/htpasswd, directory services, что ещё?)

  • LDAP как окончательное решение вопроса аутентификации

  • Практика: ?

    • Если рассмтаривать HTTP-only сервисы, можно показать на примере htpasswd/htdigest
    • Если не только их (git?) — таки да, нужен LDAP
• Организация работы с фичами и багами, ticket system, request tracking
  • Баги и фичи как важный аспект процесса разработки
  • Организация работы с багами и фичами как основополагающий аспект совместной разработки
    • Понятие тикета
    • Понятие milestone и версии
  • Пример организация bug tracking с использованием только средств VCS
  • Trac как пример lightweight ticket system
    • Зависимости тикетов
    • Планирование выполнения
    • Оповещение
    • Связь с VCS (связанные коммиты, закрытие тикетов коммитами)

  • Практика: развёртывание Trac

  • Redmine как пример полновесной ticket system
• Организация информационного пространства, Wiki
  • Информационное пространство как место сохранения тайного знания
  • Использование VCS как хранилища знания
  • Wiki как способ организации информационноо пространства
    • Связь с ticket system — кросслинкинг, in-place queries
  • Moin как пример wiki
  • (?) Moin2 как пример wiki, интегрирующейся с VCS
  • Что бывает ещё (исключительно обозначить, закинуть идеи в головы): всякие IM с поддержкой multi-user chat, аудио, видео.

  • Практика: развёртывание moin/moin2

• Качество кода: style guides, review, documentation
  • Качественный код как важный аспект совместной эффективной разработки
    • Единство и хорошесть стиля
    • Документированность
    • Надсинтаксические аспекты
  • Style guidelines как способ решения проблемы стиля кода
  • style checkers/formatters как способ форсирования style guidelines (indent, что ещё)
    • Использование совместно с VCS
  • Doxygen как пример средства самодокументирования. Специализированные средства: sphynx (python)
  • Review кода как способ решения проблемы надсинтаксических аспектов качества кода
    • Review кода и DVCS workflow
      • git format-patch
  • Reviewboard как пример

  • Практика: настройка pre-commit хуков, проверяющих style guidelines

  • Практика: настройка post-commit хуков, применяющих style guidelines

  • Практика: настройка post-commit хуков, перегенерирующих документацию к коду

  • Практика: установка и настройка review board

• Оформление результата: сборка, тестирование, packaging, deployment
  • Автоматизированная сборка как важный аспект совместной разработки
    • Воспроизводимость
    • Различные окружения и приспособление к ним
  • Упоминание make, autotools, cmake, scons как инструментов автоматизированной сборки
  • Тестирование — выявление регрессий, контроль качества, часть ревью, источник тикетов
    • Интеграция с DVCS workflow
    • Интеграция с ревью
    • Организация выдачи окружений на примере openvz
  • Packaging, tar.gz-rpm-deb как примеры
  • Deploy, пример схем деплоя (см. rider vs gosuslgi)

  • Практика: развёртывание buildbot (?)

  • Практика: развёртывание сборочницы и репозитария, интеграция с buildbot, интеграция с DVCS.

  • Практика: развёртывание и настройка выдачи доступа к openvz-окружениям