Разработка кода информационных систем

1.

Серпуховский Городской Открытый Колледж
Преподаватель – Криворуков Роман Анатольевич
МДК. 05.02 Разработка кода информационных систем.
3. Организация работы в команде разработчиков. Системы контроля версий

2.

Жизненный цикл разработки ПО и ИС.

3.

Жизненный цикл разработки ПО
Жизненный цикл (ЖЦ) ПО - это непрерывный процесс,
который начинается с момента принятия решения о
необходимости его создания и заканчивается в момент его
полного изъятия из эксплуатации.
Пять основных этапов жизненного цикла программного
продукта.
• Планирование
• Проектирование
• Кодирование и написание документации
• Тестирование и исправление недостатков
• Сопровождение (после выпуска) и усовершенствование

4.

Жизненный цикл ПО
Фазы жизненного цикла:
концепция (инициация, идентификация, отбор)
определение (анализ)
выполнение (практическая реализация или внедрение,
производство и развертывание, проектирование или
конструирование, сдача в эксплуатацию, инсталляция,
тестирование и т.п.)
закрытие (завершение, включая оценивание после
завершения)

5.

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

6.

Каскадная модель
В 1970 году У. У. Ройс (W. W. Royce) описал в виде концепции то, что сейчас
принято называть «модель водопада».

7.

V‐ОБРАЗНЫЙ ЖИЗНЕННЫЙ ЦИКЛ
Проверка
требований
Требования
Проверка
функций
Функции
Архитектура
Код
Проверка
архитектуры
Проверка
кода

8.

Инкрементная модель
Она объединяет элементы последовательной водопадной модели и итерационной моделью.
(предложена Б. Боэмом как усовершенствование каскадной модели).
Интремент – приращение функционала. Каждая линейная последовательность здесь
вырабатывает поставляемый инкремент ПО.
Анализ
Анализ
требований и
тестирование
требований
Проектирование
Анализ
Кодирование
Проектирование
Анализ
Тестирование
Кодирование
Проектирование
Поставка 1 блока
Тестирование
Кодирование
Поставка 2 блока
Тестирование
Поставка 3 блока

9.

Спиральная модель

10.

Спиральная модель. MSF - MICROSOFT
SOLUTIONS FRAMEWORK

11.

Итеративная модель. Rational
Unified Process
Итеративная разработка ПО — это процесс создания программного
обеспечения, который осуществляется небольшими этапами, в ходе
которых ведется анализ полученных промежуточных результатов,
выдвигаются новые требования и корректируются предыдущие этапы
работы.
RUP был создан в 1996г. корпорацией Rational при участии Гради Буча,
Айвара Якобсона и Джима Румбаха.
В конце каждой итерации (в идеале продолжающейся от 2 до
6 недель) проектная команда должна достичь
запланированных на данную итерацию целей, создать или
доработать проектные артефакты и получить
промежуточную, но функциональную версию конечного
продукта.

12.

13.

Agile
Agile – семейство методологий
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий
контракта
Готовность к изменениям важнее следования первоначальному
плану
То есть, не отрицая важности того, что справа, мы всё-таки
больше ценим то, что слева.

14.

Agile. Scrum
Product Backlog — это полный список всех работ, при реализации которых мы получим
конечный продукт.
Sprint Backlog — это список работ, который определила команда и согласовала
с Владельцем продукта, на ближайший отчетный период (спринт). Задания в спринт-бэклог
берутся из product-бэклога.
Sprint — отрезок времени, который берется для выполнения определенного
(ограниченного) списка задач. Рекомендуется брать 2-4недели (длительность определяется
командой один раз).

15.

Системы контроля версий. Git.

16.

Системы контроля версий
Назначение
Представители:
• CVS
• TFS
• GIT
•…и многие другие
Виды:
• Локальные
• Централизованные
• Распределенные

17.

Задачи систем контроля
версий
Хранение исходного кода проекта
Хранение истории изменений и/или
разных версий (веток) проекта
Обеспечение совместной разработки
Распределенная работа

18.

Git – распределенная
система
управления версиями
• Позволяет каждому разработчику иметь локальную
копию всей истории разработки (репозиторий)
• Заточена на использование скриптов
• Поддерживает быстрое ветвление и слияние при
нелинейной разработке
• Копирование репозиториев
• Удаленный доступ к репозитариям
• Используется во множестве свободных проектов,
сама идёт по свободной лицензии (GPL)

19.

Принцип хранения в Git
• Коммит (commit) – набор измененных / добавленных /
удаленных файлов, сохраненных вместе единой
операцией
• Репозиторий (repo, реп) – множество коммитов,
сохраненных
в виде истории развития проекта.

20.

Принцип хранения в Git
(продолжение)

21.

Хэш-функция
• Хэш-функция (функция свёртки) — функция,
осуществляющая преобразование массива входных
данных произвольной длины в (выходную) битовую
строку установленной длины, выполняемое
определённым алгоритмом.
• Git использует алгоритм SHA-1 для реализации
хэша, выдающий 20 байтный хэш (40
шестнадцатеричных символов).
Данные
произвольного
размера
Хэш-функция
(SHA-1)
20 байтный хэш
(ab3574f…)

22.

Установка и настройка
• Оригинал с сайта https://git-scm.com/
• Три хранилища конфигурации:
• global (домашняя папка пользователя)
• system (git/etc)
• local (репозиторий)
• Важные настройки:
• user.name
• user.email
• core.editor
• git config --global user.name "Sergey"

23.

Создание репозитория
• git init – пустой репозитроий в рабочей папке (.git)
• git clone адрес_оригинал [новое
имя]-клонирование существующего.
• при
клонировании
происходит
не
просто
копирование но и настройка связи с удаленным
(оригинальным репозиторием)
• Протоколы: file:// https:// ssh:// git://
• --bare создание «голого» репозитория (без рабочей
папки). Полезен на сервере для хранения и обмена
коммитами.

24.

Основные области
хранения

25.

Основные команды подготовки и
создания коммита
• git add файл – добавление нового /модифицированного
файла (файлов) в индекс (stage)
• git status – проверка состояния (полезно перед
коммитом)
• git diff [--cached] – просмотр изменений (патча)
• git commit – сохранение коммита на основе индекса
• -m - указание комментария в строке -a - включение в
индекс всех измененных отслеживаемых файлов (но не
новых!)
• git commit –am “мой комментарий”
• git rm файл – удаление (в т.ч с диска)
• git mv файл – переименование (rm + add)
• Файл .gitignore для игорирования git’ом файлов рабочей
папке

26.

Состояния файлов
(с точки зрения Git)

27.

История коммитов
• git log – средство просмотра истории в разных
вариантах
• -p (--patch) – изменения, внесенные коммитом (патчи)
• -число– указанное число последних коммитов
• --oneline – одна строка на коммит
• --all – коммита всех веток (иначе только текущей)
• --graph – дерево ветвления
• --stat – статистика по коммиту
• --pretty=format:”%h - %an” произвольный формат
• --since --until – фильтр по дате/времени
• --author – фильтр по автору
• --grep – поиск по строке комментария
• -S – поиск по добавленной/удаленной строке в
содержимом

28.

Удаленный (remote)
репозиторий

29.

Команды работы с
удаленным репозиторием
• git clone адрес_оригинал [новое имя]• git fetch – забрать изменения (без объединения с
локальными коммитами)
• git pull – забрать изменения и объединить (merge)
(сделать до отправки своих изменений)
• git push – отправить свои изменения
• git remote -v – связи с удаленными репозиториями
• git remote show имя – подробная информация о
связи с удаленным репозиторием
• git remote add имя адрес – добавить еще одну
связь с удаленным репозиторием

30.

Добавление связи с
удаленным (remote)
репозиторий

31.

Отправка изменений

32.

Получение
изменений

33.

Операции отмены изменений
• git commit --amend – замена последнего коммита
(если что то забыли включить, неверно написали
комментарий и т.п.)
• git rm --cached файл – удаление изменения
из индекса
• git restore файл – восстановить измененный в
рабочем каталоге файл (изменения потеряются!)
• git checkout хэш_коммита -- файл –
восстановить файл из коммита

34.

Ветвление
• В системах контроля версий ветвление – это возможность
вести параллельную историю разработки, независимо от
основной линий.
• Каждую ветку можно рассматривать как собственную
линейную последовательность изменений.
• Во многих системах контроля версий ветвление (и
дальнейшее слияние) – операции затратные, т.к. может
происходить физическое копирование проекта
• В Git’е наоборот – ветвление очень быстрая операция, за счет
организации веток как ссылок на коммиты.
• Git подталкивает разработчиков к активному использованию
ветвления и слияния как можно чаще при внесении
отдельных изменений.
• Специальная ссылка HEAD указывает на текущую ветку
(ссылка на ссылку на коммит).
• Именно текущая ветка-ссылка (по ссылке HEAD)
перемещается на вновь созданный коммит.

35.

Хранение отдельного коммита

36.

История коммитов

37.

Ветки как ссылки на коммит

38.

Команды управления ветками
• git branch - список веток
• -a – все ветки (включая ветки слежения)
• -v – подробная информация о коммите
• git branch новая_ветка – создание новой ветки
• git checkout ветка – переключение на новую ветку.
• Происходит обновление рабочей папки содержимым коммита,
на который указывает ветка и перестановка HEAD. Может не
сработать при наличии несохраненных изменений в рабочей
папке.
• git checkout –b новая_ветка – создание новой ветки и
переключение на неё
• git branch –d ветка – удаление ветки (удаляется только
ссылка, но не коммит)

39.

Линейная история коммитов ветки

40.

Создание новой ветки
git branch iss53
git checkout iss53
или сразу
git checkout –b iss53

41.

Создание коммита в новой ветки
git commit

42.

Создание еще одной ветки
и
git checkout master
коммит в ней
git checkout –b hotfix
git commit

43.

Основы слияния веток (merge)
• Слияние веток (merge) – перенос изменений коммитов одной
ветки в другую ветку.
• Технически слияние может выполнено:
• простой перестановкой указателя ветки на коммит другой ветки (fastforward - перемотка). Возможно в случае если одна ветка является
прямым потомком другой (прямо восходит) к ней.
• созданием нового коммита (коммит слияния), содержащего
изменения обеих веток. Такой коммит будет иметь двух родителей.
Возможно возникновение неразрешимых автоматически конфликтов
(при изменении одних и тех же строк в одном файле).
• git merge ветка – слияние текущей ветки (HEAD) с указанной.
Меняет текущую ветку(!)
• После
ручного
разрешения
конфликта
git add файл и сделать вручную git commit
выполнить

44.

Fast-forward merge (перемотка)
git checkout master
git merge hotfix

45.

Создание коммита слияния
git checkout master
git merge iss53

46.

Перебазирование (rebase)
• Перебазирование (rebase) – перенос изменений коммитов
одной ветки в другую путем создания новых коммитов с теми
же изменения в линейной истории второй ветки.
• В истории коммитов выглядит как переносы точки
ответвления на другой коммит (перебазирование) и
превращение параллельной истории в последовательную.
• Технически при переносе создаются новые коммита, а не
переносятся старые (!)
• Является альтернативой слиянию, позволяя
историю коммитов (дерево коммитов).
изменить
• При работе с удаленными репозиториями не перемещайте
ветки отправленные во внешние репозитории, т.к. это может
привести к необбходимости повторного слияния коммитов
коллег и усложнению дерева коммитов.

47.

Подготовка
git checkout –b experiment
git commit
git checkout master
git commit

48.

Вариант слияния
git checkout master
git merge experiment

49.

Вариант перебазирования
git checkout experiment
git rebase master

50.

Перемотка после
перебазирования
git checkout master
git merge experiment

51.

Сложный случай

52.

Перебазирование части коммитов
git rebase --onto master server client

53.

Удаленные ветки и ветки слежения
• Удалённые ссылки — это ссылки (указатели) в ваших
удалённых репозиториях
• git remote show origin
• Ветки слежения — это ссылки на определённое
состояние удалённых веток. Это локальные ветки,
которые нельзя перемещать
• Git перемещает ветки слежения автоматически при
обмене данными с удаленным репозиторием (fetch,
push, pull)
• Имена веток слежения: remote_repo/branch –
например origin/master
• Ветки слежения используются для внесения изменений
полученных с удаленного репо в локальные ветки путём
слияния.

54.

Долгоживущие ветки

55.

Тематические ветки

56.

GitFlow

57.

Trunc Based Development
• Только одна долгоживущая ветка: Trunc (master)
• Все остальные ветки – короткоживущие – максимум 2 дня
• Feature flags – флаги, которые позволяют включать или
выключать тот или иной функционал. Это позволяет в
ветке master всегда иметь код, готовый к
разворачиванию.
• Изменения, вносимые в ветку master (например через
pull request), должны привносить отдельные абстракции,
а не целые блоки функционала.
• Pull request рассматривается короткое время (10 мин),
что даёт постоянные code review проекта