Курс ?Организационные аспекты совместной разработки?
Аннотация
Курс ?Организационные аспекты совместной разработки? ставит своей целью рассмотрение проблем организационного характера и технологических способов их решения в контексте совместной работы над программным проектом. В рамках курса планируется затронуть следующие аспекты совместной разработки: совместная работа над кодом; отслеживание ошибок и недостающих возможностей; организация информационного пространства; отслеживание качества кода; вопросы сборки, тестирования и развертывания. Курс ориентирован на администраторов, перед которыми встала задача организации подобного процесса совместной разработки, но также может оказаться полезен и людям, планирующим участвовать в рассматриваемых видах проектов.
План курса
- Введение.
- Зачем этот курс
Курс предназначен для администраторов, перед которыми встала задача организации процесса совместной разработки. В идеале, рассматриваемая в курсе совокупность инструментов должна позволять решать поставленную задачу данного рода ? ?сделать так, чтобы программисты программировали с минимумом затрат на непроизводительную деятельность?.
- Структура курса, почему так
Вообще, рассматриваемые аспекты завязаны друг с другом в практически полносвязный направленный граф. Тем не менее, авторы попытались выделить некоторую последовательность изложения, при которой будет сделано минимум ссылок вперед.
В курсе не рассматриваются вопросы организации рабочего места программистов, это довольно отдельная тема, которая больше завязана на различные внешние факторы и привычки собственно программистов.
- Зачем этот курс
- VCS
- Зачем VCS
- Use cases и вытекающие из этого свойства
- DVCS
- Workflow при использовании DVCS
- Git как пример (D)VCS
- Управление репозиториями
Практика: развертывание 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
- Review кода и DVCS workflow
- 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-окружениям
- Автоматизированная сборка как важный аспект совместной разработки