1. Почему важны не используемые инструменты, а модель организации работы и стратегия выпуска релизов. 2. Переход к более информативной истории изменений: от летописи разработки к истории развития продукта. 3. Связь между системами управления проектом и исходным кодом должна быть двусторонней. 4. Выбор разумной политики создания веток. 5. Хорошая архитектура и постоянное слияние делают непрерывную интеграцию более эффективной.

1. 1
Go# Conferences – Team Leaders Day
Глушенков Виктор
Взаимное влияние SCM и других
средств организации разработки
v.glushenkov@ts-soft.ru
@artplastika

2. 2
Go#Conferences–TeamLeadersDay
Разработчики
 любят самостоятельную работу
 не любят отчитываться
 любят чёткую постановку задачи
 концентрируются на коде
 предпочитают технические решения
 воспринимают каждый инструмент индивидуально

3. 3
Go#Conferences–TeamLeadersDay
Каждому инструменту своё
Архитектура
Управление
проектом
Среда
разработки
Continuous
Integration
SCM
Выпуск
релизов

4. 4
Go#Conferences–TeamLeadersDay
Хороший коммит
 решает одну задачу
 содержит ссылку на задачу
 содержит описание (комментарий)
 не ломает систему (в общем случае)
и т.д.

5. 5
Go#Conferences–TeamLeadersDay
Испытывали ли вы ступор?

6. 6
Go#Conferences–TeamLeadersDay
Что пишут в сообщение коммита?
 Ничего
 Что придёт в голову
 Что было реализовано
 Номер задачи (тикета)
 Номер задачи и название
 Подробное описание (Торвальдс)

7. 7
Go#Conferences–TeamLeadersDay
Бессодержательные сообщения

8. 8
Go#Conferences–TeamLeadersDay
Непонятные с ходу сообщения

9. 9
Go#Conferences–TeamLeadersDay
№ задачи + название = сообщение
Управление задачами:
 декомпозиция
 самодокументирование
системы
 более цельное восприятие
компонентов системы
 глубже понимание сути
задачи
 возможность
автоматического
связывания задачи и
коммита
Управление кодом:
 нет «царь-коммитов»
 нет рутины для
разработчика при
комментировании коммита
 понятная история
изменений в репозитории

10. 10
Go#Conferences–TeamLeadersDay
Об интеграции со средой разработки
 Исходный код проекта для среды разработки — это не
весь исходный код системы
 При фиксации изменений легко забыть то, что за
рамками программного кода (скрипты, документы и т.д.)
 Конфликты при слиянии могут сделать проект
некорректным для среды разработки, править всё равно
придётся в другом редакторе
В общем, коммит из среды — не лучшая идея

11. 11
Go#Conferences–TeamLeadersDay
Политики создания веток
 под функционал (фичу)
 под компоненты системы
 по версиям продукта
 на каждого разработчика
 для разделения разработки и выпуска релизов
и другие, а также их комбинации

12. 12
Go#Conferences–TeamLeadersDay
Взаимное влияние инструментов
Архитектура
Управление
проектом
Среда
разработки
Continuous
Integration
SCM
Выпуск
релизов
ветки,
коммиты
модульность
ветки, коммиты
декомпозиция,
документация
модульность
ветки, коммиты
срезыкоммиты история
изменений

13. 13
Go#Conferences–TeamLeadersDay
Всем спасибо!
Обсуждение можно продолжить:
в блоге компании: ts-soft.ru/blog/scm-influence
на моём сайте: artplastika.ru
в переписке: v.glushenkov@ts-soft.ru