1. Совместная разработка
Инструменты и технологии.

2. О чём поговорим
● Системы версионирования
● Юнит-тесты
● Непрерывная интеграция

3. О чём не поговорим
● Style Guide
● Системы управления проектом (http:
//basecamp.com и http://asana.com/)
● Системы учета ошибок (http://bugzilla.org и
http://redmine.org)
● Функциональное тестирование (e.g.:
selenium)
● Тестирование безопасности (e.g.:
w3af+nikto+nmap)
● Остальное тестирование (e.g.: ab)

4. Системы управления версиями
(СУВ, VCS)
From Wiki:
Набор программных средств для
управления изменениями в документах,
программах, веб-сайтах и других данных,
хранимых в файлах

5. Нумерация версий
Просто нумерованные папки
Больше ничего

6. Проблемы
● Совместный доступ к коду
● Когда редактировали?
● Кто редактировал?
● Что изменилось?
● Контроль версий
● Контроль доступа пользователей

7. Системы контроля кода ПО (SCM)
Или системы управления конфигурацией
ПО.
Cредство и соответствующий процесс,
используемый для поддержки исходного
кода и его изменения с течением времени

8. Задачи SCM
● Поддержка файлов в репозитории
● Поддержка проверки файлов в репозитории
● Нахождение конфликтов при изменении исходного
кода и обеспечение синхронизации при работе в
многопользовательской среде разработки
● Отслеживание авторов изменений
● Журналирование изменений
● Возможность управления конфигурацией файлов (в
частности, проверки) для совместимых и
повторяющихся сборок.

9. Язык SCM
Репозиторий (repository) - это центральное место, где
хранятся файлы
Извлечение файлов из репозитория в рабочую
директорию вашей локальной системы называется
выгрузка (check-out).
Синхронизация изменений в локальных копиях с
изменениями в репозитории называется фиксацией
изменений (commit)
Если объединение невозможно из-за конфликтующих
изменений в файле, возникнет конфликт (conflict).

10. Язык SCM
Когда изменения зафиксированы, создается новая
версия (revision) файла
У одного или нескольких разработчиков есть
возможность работать вне главного дерева (текущего
корня репозитория), а именно, в персональной ветке
(branch).
Это позволяет разработчикам испытывать какие-то
процессы в своих ветках, не влияя на главное дерево.
Когда они станут стабильными, их можно соединить
(merge) с главным деревом.

11. Язык SCM
Пометка начала отсчета изменений в дереве (tag)
Группирует несколько файлов в пригодный для
использования блок
Чаще всего используется для обозначения конечной
версии файлов для сборки

12. Централизованные SCM

13. Эволюция SCM: CVS
Concurrent Versions System
Клиент-серверная архитектура
Сервер хранит репозиторий
Клиент обращается к серверу

14. CVS: команды
● check-out
● check-in == commit
● update
● branch

15. CVS: недостатки
● 1 коммит/файл
● Невозможно переименовать файл или
директорию
● Нет поддержки юникода
● Неэффективное хранение бинарных
файлов
● Нет ограничения прав доступа
● Публикация изменений не атомарна
● Нет поддержки непубликуемых файлов
● Неэффективная работа с бинарными
файлами

16. Эволюция SCM: SVN
Замена CVS
● Поддерживаются наборы изменений
● Полная история изменений
● Поддержка блокировок
● Фиксация изменения атомарна
● Одинаково эффективная работа как
текстовыми так и с двоичными данными
● При синхронизации передаются только
изменения

17. SVN: структура и команды
svn init /.
svn add trunk
branches
svn checkout
branch_1
svn commit tags
svn revert tag_1
svn update tag_2
svn log
svn copy
svn merge
svn switchto

18. SVN: Недостатки
● Проблемы при переименовании файлов
● Слабая поддержка слияния ветвей.
Слияние переименованных файлов и
папок не поддерживается
● Невозможность удаления данных из
хранилища (!)

19. Распределенные SCM

20. Распределенные SCM
● Нет главной копии, все копии рабочии
● Возможно множество центральных
репозиториев
● Локальные изолированные репозитории
для изменений
● Асинхронная работа в p2p-сети (в
централизованной системе star-
архитектура)
● Большинство операций (commit, merge,
diff и.т.п.) производятся без
использования сети

21. Распределенные SCM:
Преимущества
● Автономность разработчика
● Гибкость системы
● Слияние (и зачастую др. операции)
происходит быстрее
● Контроль доступа

22. Распределеные SCM: недостатки
● Нет блокировок
● Слежение за файлом или группой файлов
проблематично
● Нет единой нумерации версий
● Медленное клонирование репозитария
● Репозиторий занимает много места на
диске пользователя

24. Распределенные SCM: Git
Любой программист вправе продолжить
совершенствование проекта на любом его этапе
● Локальная копия репозитория для каждого
разработчика
● Быстрое разделение и слияние версий
● SHA1-хеш для нумерации версии

25. GIT: Операции
● git init
● git add
● git clone
● git commit
● git merge
● git reset
● git push <url> <branch>
● git pull
● git diff
● git log

27. Git: ветки

28. GIT: преимущества
● Децентрализован
● Прост в использовании (хорошие
средства для автоматического слияния)
● Хорошо спроектирован

29. GIT: недостатки
● Unix-ориентированность
● Коллизии хеширования
● Проблемы при больших репозитариях
● Проблемы на больших проектах
● Написан на C (0_o :))

30. Блочное тестирование

31. Получение работоспособного кода
с наименьшими затратами

32. Изолировать отдельные части
программы и показать, что по
отдельности эти части
работоспособны

33. Unit-тестирование
Метод тестирования, в котором отдельные модули
программы проверяются на готовность к
использованию
Модуль (unit) - наименьший участок кода системы,
пригодный к тестированию
В процедурном подходе модуль - процедура/функция
В ООП - класс, интерфейс. Может быть метод.

34. public class TestAdder {
public void testSum() {
Adder adder = new AdderImpl();
// can it add positive numbers?
assert(adder.add(1, 1) == 2);
assert(adder.add(1, 2) == 3);
assert(adder.add(2, 2) == 4);
// is zero neutral?
assert(adder.add(0, 0) == 0);
// can it add negative numbers?
assert(adder.add(-1, -2) == -3);
// can it add a positive and a negative?
assert(adder.add(-1, 1) == 0);
// how about larger numbers?
assert(adder.add(1234, 988) == 2222);
}
}

35. Вариант тестирования (test case)
● Уникальный идентификатор варианта тестирования
● Краткое описание варианта тестирования
● Стадия теста или порядок выполнения
● Требования
● Глубина теста
● Категория теста
● Автор
● Флаг автоматизации теста
● Ожидаемый результат/Реальный результат
● Пройден/Провален

36. Пишем тесты для каждой
нетривиальной функции или
метода

37. 1 строка кода = 3-5 строк теста

38. Unit-тестирование
● Нет смысла писать тесты на весь код
● Более выгодно писать тесты на
потенциально изменяемый код
● Чтобы реже менять тесты, нужно хорошо
проектировать интерфейсы

39. Unit-тестирование: преимущества
● Легче вносить изменения в структуру
программы
● Упрощение интеграции
● Документирование кода (грязный хак :))
● Отделение интерфейса от реализации

40. Unit-тестирование: недостатки
● Отлавливаются не все ошибки
● Комбинаторная задача
● Требование следования технологии
тестирования...
...
● ...Иначе лавина

41. Непрерывная
интеграция

42. Выполнение частых автоматизированных
сборок проекта для скорейшего
выявления и решения интеграционных
проблем

43. CI
На сервере:
● получение исходного кода из репозитория;
● сборка проекта;
● выполнение тестов;
● развёртывание готового проекта;
● отправка отчетов.
Выполняется
● по внешнему запросу;
● по расписанию;
● по факту обновления репозитория или другому
событию

44. CI: преимущества
● проблемы интеграции выявляются и исправляются
быстро, что оказывается дешевле
● немедленный прогон модульных тестов для свежих
изменений
● постоянное наличие текущей стабильной версии
вместе с продуктами сборок — для тестирования,
демонстрации, и т. п.
● немедленный эффект от неполного или
неработающего кода приучает разработчиков к
работе в итеративном режиме с более коротким
циклом

45. CI: недостатки
● Затраты на поддержку работы
● Необходим выделенный сервер под
нужды интеграции
● Немедленный эффект от неработающего
кода демотивирует команду загружать
промежуточные версии кода
○ Ветвление в SCM частично решает проблему