1. Управление на промените при разработка на софтуер Светлин Наков Национална академия по разработка на софтуер academy.devbg.org ( Software Configuration Management )
2. Съдържание Системи за управление на промените при разработка на софтуер ( SCM) Пазарът на SCM продукти Управление на версиите – основни понятия и принципи Модели на версионизация Lock-Modify-Unlock Copy-Modify-Merge Етикети и разклонения
3. Какво е управление на промените? Управление на промените ≈ Software Configuration Management Контрол на промените по време на целия процес на разработка на софтуер При бизнес анализа, при изготвянето на архитектурата и планирането, при имплементацията и тестването Позволява промените да се преглеждат преди да бъдат одобрени
4. Software Configuration Management ( SCM) Дисциплина от софтуерното инженерство Състои се от техники, практики и инструменти Управлява промените при разработка на софтуерни проекти чрез: Механизми за управление, контрол, одитиране и отчетност на промените Дефинира процеса на промяна Проследява какво се случва в проекта Решава конфликти в промените
5. Защо ни трябва SCM? Да управляваме : Много хора работещи по едни и същи сорс код или документи Проекти, предавани в много издания ( builds & releases) Проследяването на еволюцията на софтуера и развитието на проекта: Статус, напредък, дефекти, функционалност, ... Управление на конкурентния достъп
6. Ползи от SCM системите (1) Управление на промените Контрол над развитието на продукта и промените Отчитане на напредъка Следене на статуса на отделните компоненти и напредъка на работата по тях Преглеждане и одитиране Възможност за преглеждане на промените Управление на билдовете ( build) Следене на билдовете и информация за тях
7. Ползи от SCM системите (2) Управление на процеса Следване на процеса на разработка Работа в екип Улесняване на съвместната работа и взаимодействията в екипа
8. SCM и процесът на разработка на софтуер Сорс код Модели Build скриптове, готов продукт Тестови скриптове и данни Готов продукт Изисквания Имплементация Дизайн Издаване Тестване Анализ Издание SCM
10. Пазарът на SCM продукти Process-centric software configuration management Software configuration management (SCM) Version control Application life-cycle management (ALM)
11. Системи за управление на версиите ( Version Control) Функционалност Управление на версиите на файлове Просто сливане и намиране на разлики Разклоняване ( branching) Заключване на файлове Конзолни и GUI клиенти По-известни продукти CVS Subversion Microsoft Visual SourceSafe Perforce
12. SCM системи Функционалност Управление на групи документи Подобрено сливане и разлики Управление на работно пространство Управление на поток на събитията ( workflow) Управление на билдове и издания По-известни продукти Borland StarTeam Standard IBM Rational ClearCase MKS Source Integrity Serena ChangeMan Professional
13. Процесно- ориентирани SCM системи Функционалност Шаблони за процеса, дизайна и имплементацията Управление на изискванията Управление на проблеми ( issue tracking) Управление на задачи, промени по задачи Контрол на достъпа (потребители, групи, ...) Аналитични средства и отчети за напредъка По-известни продукти Borland StarTeam Standard IBM Rational ClearCase MKS Source Integrity
14. Application Lifecycle Management (ALM) системи Функционалност Тясна интеграция на процесите с инструменти за прилагането им Инструменти за дизайн Инструменти за разработка Инструменти за тестване Инструменти за управление на проекта По-известни продукти Microsoft Visual Studio Team System Server Borland StarTeam Enterprise Advantage Telelogic SYNERGY
16. Управление на версиите Използва се постоянно в инженерството При работа с документи При разработка на софтуер Промените се идентифицират с увеличаване на пореден номер “ номер на версия ” , напр. 1.0, 2.0, 2.17 Номерата на версиите исторически са свързани с лицето, което ги е създало
17. История на промените Системите за контрол на версиите запазват пълна история на промените Пазят се датата и часа на всяка промяна Пази се потребителят, направил промяната Старите версиите могат да се извличат, разглеждат и сравняват Възможно е връщане към стара версия ( revert)
18. Речник на термините (1) Хранилище ( repository) Сървър, който съхранява файловете (документите) Поддържа история на версиите Версия ( revision, version) Индивидуална версия (състояние) на файл, получена след серия промени Извличане ( check-out ) Извлича работно копие на файловете от хранилището в локална директория Възможно е заключване на файловете
19. Речник на термините (2) Промяна ( change) Модификация на локален файл (документ), за който се контролират версиите Списък с промени ( change list) Множество от промени в различни файлове, които ще бъдат потвърдени наведнъж Потвърждаване ( commit, check-in) Изпращане на промените от локалното копие на файловете в хранилището Създава автоматично нова версия Възможно е настъпване на конфликти!
20. Речник на термините (3) Конфликт ( conflict) Едновременна промяна на един и същ файл от няколко потребителя Автоматично и ръчно разрешаване Обновяване ( update , get latest version) Извличане на променените файлове от хранилището в локална директория Връщане на промените ( undo check-out) Отказва започнати промени по група файлове Връща състоянието им от хранилището
21. Речник на термините (4) Сливане ( merge) Сливане на промени върху един и същ файл, направени паралелно от различни потребители Може в голяма степен да се автоматизира Етикет ( label , tag) Етикетите отбелязват с име група от файлове в дадена версия Например дадено издание ( release) Разклоняване ( branching) Разделяне на хранилищата в няколко отделни потока на работа
22. Управление на версиите: типичен сценарий Потребители Хранилище Главна линия на разработка Потребител A Потребител B Version B Branch Version A Branch Version A.1 Branch Check Out A Check In C Check In E Check Out B Merge D
24. Модели на версионизация Заключване-промяна-отключване ( Lock-Modify-Unlock ) : Само един потребител работи по даден файл в даден момент, без конфликти Пример : Visual SourceSafe Копиране-промяна-сливане ( Copy-Modify-Merge ) : Потребителите правят паралелни промени по собствените си работни копия Паралелните промени се сливат и се получава финалната версия Примери : CVS, Subversion
25. Проблеми със заключването Административни проблеми: Някой заключва даден файл и забравя за него Губи се време в чакане някой да освободи даден файл Ненужно заключване на целия файл Различните промени не винаги са в конфликт Например: Асен работи в началото, а Боби – в края на файла
26. Проблеми със сливането Ако даден файл се променя едновременно ( modify concurrently), промените трябва да се сливат Сливането е трудно! Не винаги е възможно автоматично Необходима е отговорност и координация между разработчиците Правете commit възможно най-бързо Не правете commit на код, който не се компилира или спира работата на другите Поставяйте коментари при commit
27. Сравнение на файлове При ръчно сливане ползвайте сравнение на версиите Съществуват визуални графични инструменти за сравнение: Windiff AraxisMerge BeyondCompare CompareIt …
30. Моделът Lock-Modify-Unlock (1) Хранилище Асен и Боби извличат ( update ) файл A. Извличането е без заключване – просто взимат локално копие. Update Update Асен Боби A A A
31. Моделът Lock-Modify-Unlock (2) Хранилище Асен Асен заключва ( lock ) файл A и започва да го променя. Lock Асен Боби A A
32. Моделът Lock-Modify-Unlock (3) Хранилище Асен Боби се опитва също да заключи файла, но не може. Боби чака докато Асен приключи работа и отключи файла. Wait Асен Боби A A
38. Моделът Copy-Modify-Merge (1) Хранилище Боби и Асен извличат за редакция файл A (check-out). Извличането е без заключване. Асен Боби Check-out Check-out A A A
39. Моделът Copy-Modify-Merge (2) И двамата редактират локалните копия на файловете. Хранилище Асен Боби A
40. Моделът Copy-Modify-Merge (3) Хранилище Боби Асен Боби Боби изпраща (commit) своите промени в хранилището. Commit
41. Моделът Copy-Modify-Merge (4) Асен опитва да изпрати ( commit) своите промени. Получава се конфликт на версиите. Commit Хранилище Боби Боби Асен
42. Моделът Copy-Modify-Merge (5) Асен обновява (update) своите промени с тези от хранилището. Промените се сливат в локалното му копие. Може да се получи конфликт при сливане ( merge conflict). Update (with merge) Хранилище Боби Боби Асен & Боби
43. Моделът Copy-Modify-Merge (6) Хранилище Асен нанася промените в хранилището. Вкарва се обща версия с промените на Асен и Боби. Commit Боби Асен & Боби Асен & Боби
44. Моделът Copy-Modify-Merge (7) Боби обновява промените от хранилището. Взима общата версия с промените на Асен и Боби. Update Хранилище Асен & Боби Асен & Боби Асен & Боби
46. Етикети ( Tags) Позволяват да се даде име на съвкупност от файлове в определени версии Main.c Main.h 1.1 1.3 1.4 1.2 Prog.c 1.1 1.2 Tag "Beta 2" 1.1 1.3 1.2
47. Разклонения ( B ranching) Разклоненията позволяват група промени да бъдат отделени в отделна линия на разработка ( development line ) Разклоненията са подходящи за : Поправка на грешки в стара версия на продукта Разработка на допълнения в определена версия на продукта Допълненията са независими, извън основната линия на разработка
