dev collaboration
TRANSCRIPT
Совместная разработка Инструменты и технологии.
О чём поговорим
● Системы версионирования● Юнит-тесты● Непрерывная интеграция
О чём не поговорим
● 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 частично решает проблему