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

• Введение.
  • Зачем этот курс
  • Структура курса, почему так
• VCS
  • Зачем VCS
  • Workflow/use cases и вытекающие из этого свойства
  • DVCS
  • Git как пример (D)VCS
  • Управление репозиториями

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

• Аутентификация
  • Зачем аутентификация
  • Где нужна аутентификация
  • Способы аутентификации
  • LDAP

  • Практика: ?

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

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

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

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

• Организация работы с фичами и багами, ticket system, request tracking
  • Баги и фичи как важный аспект процесса разработки
  • Организация работы с багами и фичами как основополагающий аспект совместной разработки
    • Понятие тикета
    • Понятие milestone и версии
  • Trac как пример lightweight ticket system
    • Зависимости тикетов
    • Планирование выполнения
    • Оповещение
    • Связь с VCS (связанные коммиты, закрытие тикетов коммитами)

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

  • Redmine как пример полновесной ticket system
• Организация информационного пространства, Wiki
  • Информационное пространство как место сохранения тайного знания
  • Wiki как способ организации информационноо пространства
    • Связь с ticket system — кросслинкинг, in-place queries
  • Moin как пример wiki
  • (?) Moin2 как пример wiki, интегрирующейся с VCS

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

• Качество кода: style guides, review, documentation
  • Качественный код как важный аспект совместной эффективной разработки
    • Единство и хорошесть стиля
    • Документированность
    • Надсинтаксические аспекты
  • Style guidelines как способ решения проблемы стиля кода
  • style checkers/formatters как способ форсирования style guidelines (indent, что ещё)
  • 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
    • Интеграция с ревью
  • Packaging, tar.gz-rpm-deb как примеры
  • Deploy, пример схем деплоя (см. rider vs gosuslgi)

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

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