Не только Git…

Заметка про PipEnv

Pipenv: Python Dev Workflow for Humans

• Вариант venv, хранящий окружение и кеши отдельно

• Привязывает окружение к каталогу
• Что-то дополнительно проверяет в окружении
• Не засоряет каталог проекта (только конфиг и статус-файл)

• Хранит всё неизвестно где, и вставляет это неизвестно где в $PATH

Пример.

Git: DVCS

• Хранение
• Версионирование
• Работа с историей изменений в виде орграфа

• Документирование процесса разработки

• Маркировка отдельных коммитов
  • В т. ч. аннотированные и подписанные теги

Организация взаимодействия при совместной разработке

Классическая модель (если не будет хватать времени, рассмотрим только её):

• Один публичный репозиторий, т. н. «апстрим»
• Разработчики синхронизуются с ним
• merge request-ом является электронное письмо с приложенным набором патчей

  • в git есть поддержка этого процесса (gitsend-email)

• Майнтейнер публичного репозитория делает git am и ревью, и публикует реультат

Открытая модель:

• Апстрим — один публичный репозиторий, в котором собирается работа всех участников
  • более жёсткая дисциплина «Precious source»: в этот репозиторий делается только pull и review
• Разработчики синхронизуются с ним
• Индивидуальные публичные репозитории всех участников
• Решённые (под)задачи участники публикуют в индивидуальных публичных репозиториях
• merge request-ом является оповещение о готовности индивидуального репозиотрия к merge-у со стороны исполнителя (ссылка на commit-ish — коммит, тег, ветку и т. п.)

• Майнтейнер апстрима делает git pull и ревью, и публикует реультат

Модель общего хостинга:

• В плане использования GIT совпадает с открытой моделью

• Все дополнительные инструменты разработки могут быть привязаны к git или даже управляться тегами, но в самом git отсутствуют

• Выделяют «pull request» (GitHub) или «merge request» (GitLab) в качестве отдельного информационного объекта и обеспечивают (полу)автоматическую его обработку.

  • Важно: понятие merge/pull request в самом git отсутствует, и у него нет чёткого определения
• Предоставляет тематическую социальную сеть с привязкой к исходным текстам и информационным объектам процесса разработки
• Предоставляет технологические ресурсы по сборке и тестированию

Централизованная модель:

• Один репозиторий для всех
• Чёткие конвенции для push и pull
• Использование веток в т. ч. для индивидуальной разработки
  • Решённые (под)задачи участники публикуют в том же самом репозитории в специально выделенных личных ветках разработки
• Важно: раздельных прав доступа на части репозитория в git нет, это или договорённости или дополнительные свойства площадки
• А ещё это сводит на нет все достоинства DVCS

Ветки и индивидуальные публичные репозитории — ортогональные сущности:

• Ветки — для эшелонирования работ (например, разработки новой функциональности или разделения на devel - testing - deployment)
• Индивидуальные публичные репозитории — для разделения областей ответственности по исполнителям
• В индивидуальном репозитории могут быть какие угодно ветки, например, один и тот же человек может

  1. заниматься разработкой новой фичи — иметь соответствующую ветку в своём публичном репозитории и слать pull-request-ы в ветку newfeature апстрима

  2. заниматься багфиксом релизов и слать pull-request-ы в ветку production апстрима

Работа с несколькими удалёнными репозиториями

git remote (ещё тут)

• Общая история
• Произвольная синхронизация
• Но: нет встроенных инструментов уведомления
  • (actually, есть — email — но даже он требует инфраструктуры ≠ git: почтовых серверов, email-клиентов и т. п.)

Информационно-технологическое пространство проекта разработки

• Общение — списки рассылки, «team discussion», чатики, you name it

  • Как задавать вопросы

• Документирование (самого проекта и дисциплины разработки в нём) — Wiki и иные системы публикации
• Issue tracking — ошибки / feauture requests

  • Как сообщать об ошибках

  • Workflow: open → discuss → solve → close (→ reopen → …)
  • «Patches are welcome!»
• Частный случай: «pull request» (gitlab: merge request)
  • Инфопространство привязано к конкретным точкам разработки
  • Эффективно в рамках единого хостинга (в остальных случах просто моделируется, например, тредом в списках рассылки)
  • ⇒ может содержать удобные инструменты (например, итерация review)
  • Но: «подход от решения»
• CI
• Работа с командой / статистика / аналитика / …

Д/З

зарегистрировать семестровый проект

0. Завести один «precious source» репозиторий для merge и публикации проекта и персональные — для разработки (лидеру проекта допустимо вести разработку в отдельной ветке, заводить ещё один репозиотрий ненадо)
1. Разработать драфт проектного задания;
   • Постановка решаемой задачи: один абзац или список фич
   • Описание предполагаемых инструментов решения: какие сторонние модули будут использоваться, в рамках каких сервисов (если предполагаются)

   • Макет интерфейса (обратите внимание на то, что от проекта требуется локализация ⇒ какой-то интерфейс с человеком должен быть

     • GUI/TUI — общий вид окошек, что в целом они делаю и как попадают из одного в другое
     • Text — команды, диагностика (в общем плане — когда возникает и как посмотреть), режимы работы
     • …
     • Поместить проектное задание в README (или README.md) публичного репозиотория

2. Зарегистрировать публичный репозиторий проекта в качестве вашего персонального issue на странице репозитория PythonDevelopment2022. В issue указать:

   • Короткую формулировку сути проекта

   • Ссылку на публичный репозиторий проекта

   • Список участников проекта в виде:
     1. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
     2. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории …

3. См. требования к защите проекта