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

О чём поговорим

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

О чём не поговорим

● 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)

Системы управления версиями (СУВ, VCS)

From Wiki:Набор программных средств для управления изменениями в документах, программах, веб-сайтах и других данных, хранимых в файлах

Нумерация версий

Просто нумерованные папки

Больше ничего

Проблемы

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

Системы контроля кода ПО (SCM)

Или системы управления конфигурацией ПО.

Cредство и соответствующий процесс, используемый для поддержки исходного кода и его изменения с течением времени

Задачи SCM● Поддержка файлов в репозитории● Поддержка проверки файлов в репозитории● Нахождение конфликтов при изменении исходного

кода и обеспечение синхронизации при работе в многопользовательской среде разработки

● Отслеживание авторов изменений● Журналирование изменений● Возможность управления конфигурацией файлов (в

частности, проверки) для совместимых и повторяющихся сборок.

Язык SCM

Репозиторий (repository) - это центральное место, где хранятся файлы

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

Язык SCM

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

Язык SCM

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

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

Эволюция SCM: CVS

Concurrent Versions System

Клиент-серверная архитектура Сервер хранит репозиторийКлиент обращается к серверу

CVS: команды

● check-out● check-in == commit● update● branch

CVS: недостатки

● 1 коммит/файл● Невозможно переименовать файл или

директорию● Нет поддержки юникода● Неэффективное хранение бинарных

файлов● Нет ограничения прав доступа● Публикация изменений не атомарна● Нет поддержки непубликуемых файлов● Неэффективная работа с бинарными

файлами

Эволюция SCM: SVN

Замена CVS● Поддерживаются наборы изменений● Полная история изменений● Поддержка блокировок● Фиксация изменения атомарна● Одинаково эффективная работа как

текстовыми так и с двоичными данными● При синхронизации передаются только

изменения

SVN: структура и командыsvn initsvn addsvn checkoutsvn commitsvn revertsvn updatesvn logsvn copysvn mergesvn switchto

/.trunkbranchesbranch_1tagstag_1tag_2

SVN: Недостатки

● Проблемы при переименовании файлов● Слабая поддержка слияния ветвей.

Слияние переименованных файлов и папок не поддерживается

● Невозможность удаления данных из хранилища (!)

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

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

● Нет главной копии, все копии рабочии● Возможно множество центральных

репозиториев● Локальные изолированные репозитории

для изменений● Асинхронная работа в p2p-сети (в

централизованной системе star-архитектура)

● Большинство операций (commit, merge, diff и.т.п.) производятся без использования сети

Распределенные SCM: Преимущества

● Автономность разработчика● Гибкость системы● Слияние (и зачастую др. операции)

происходит быстрее● Контроль доступа

Распределеные SCM: недостатки

● Нет блокировок● Слежение за файлом или группой файлов

проблематично● Нет единой нумерации версий● Медленное клонирование репозитария● Репозиторий занимает много места на

диске пользователя

Распределенные SCM: Git

Любой программист вправе продолжить совершенствование проекта на любом его этапе● Локальная копия репозитория для каждого

разработчика● Быстрое разделение и слияние версий● SHA1-хеш для нумерации версии

GIT: Операции

● git init● git add● git clone● git commit● git merge● git reset● git push <url> <branch>● git pull● git diff● git log

Git: ветки

GIT: преимущества

● Децентрализован● Прост в использовании (хорошие

средства для автоматического слияния)● Хорошо спроектирован

GIT: недостатки

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

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

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

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

отдельности эти части работоспособны

Unit-тестирование

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

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); }}

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

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

метода

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

Unit-тестирование

● Нет смысла писать тесты на весь код● Более выгодно писать тесты на

потенциально изменяемый код● Чтобы реже менять тесты, нужно хорошо

проектировать интерфейсы

Unit-тестирование: преимущества

● Легче вносить изменения в структуру программы

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

Unit-тестирование: недостатки

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

тестирования......● ...Иначе лавина

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

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

выявления и решения интеграционных проблем

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

событию

CI: преимущества

● проблемы интеграции выявляются и исправляются быстро, что оказывается дешевле

● немедленный прогон модульных тестов для свежих изменений

● постоянное наличие текущей стабильной версии вместе с продуктами сборок — для тестирования, демонстрации, и т. п.

● немедленный эффект от неполного или неработающего кода приучает разработчиков к работе в итеративном режиме с более коротким циклом

CI: недостатки

● Затраты на поддержку работы● Необходим выделенный сервер под

нужды интеграции● Немедленный эффект от неработающего

кода демотивирует команду загружать промежуточные версии кода○ Ветвление в SCM частично решает проблему