Различия между версиями 6 и 7
Версия 6 от 2022-03-21 19:25:32
Размер: 9973
Редактор: FrBrGeorge
Комментарий:
Версия 7 от 2022-03-30 09:32:35
Размер: 10573
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 2: Строка 2:

== Заметка про PipEnv ==
[[https://pipenv.pypa.io/|Pipenv: Python Dev Workflow for Humans]]
 * Вариант `venv`, хранящий окружение и кеши отдельно
 * Привязывает окружение к каталогу
 * Что-то дополнительно проверяет в окружении
 * Не засоряет каталог проекта (только конфиг и статус-файл)
 * Хранит всё неизвестно где, и вставляет это неизвестно где в `$PATH`

{i} Пример.

Не только Git…

Заметка про PipEnv

Pipenv: Python Dev Workflow for Humans

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

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

{i} Пример.

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
  • Частный случай: «pull request» (gitlab: merge request)
    • Инфопространство привязано к конкретным точкам разработки
    • Эффективно в рамках единого хостинга (в остальных случах просто моделируется, например, тредом в списках рассылки)
    • ⇒ может содержать удобные инструменты (например, итерация review)
    • Но: «подход от решения»
  • CI
  • Работа с командой / статистика / аналитика / …

Д/З

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

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

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

    • Короткую формулировку сути проекта
    • Ссылку на публичный репозиторий проекта

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

LecturesCMC/PythonDevelopment2022/06_SocialProject (последним исправлял пользователь FrBrGeorge 2022-03-30 09:32:35)