SE_labs

Инженерия программного обеспечения

Для начальной настройки Git-сервера, необходимо экспортировать существующий репозиторий в новый «чистый» (bare) репозиторий

— репозиторий, который не содержит рабочей копии.

$ git clone --bare my_project my_project.git

Initialized

empty

Git

repository

in

/opt/projects/my_project.git/

Для создания чистого репозитория используйте команду: git --bare init

После того, как получена чистая копия репозитория, необходимо поместить ее на Git-сервере и настроить протокол доступа к Gitрепозиторию. К примеру, есть сервер git.example.com с SSH-доступом. Для создания хранилища репозиториев на сервере в каталоге /opt/git, необходимо просто скопировать репозиторий:

$ scp -r my_project.git [e-mail]:/opt/git

В этом случае, все пользователи, которые имеют SSH-доступ к серверу и имеют доступ на чтение каталога /opt/git могут клонировать (clone) проект из репозитория, используя команду:

$

git

clone

[e-mail]:/opt/

git/my_project.git

Если ssh-пользователь имеет доступ на запись (write access) к каталогу /opt/git/my_project.git, он автоматически получит доступ на внесение изменений в репозиторий (push access).

Настроим SSH-доступ к репозиторию. Будем использовать метод authorized_keys для аутентификации пользователей. Для начала, создайте пользователя git и директорию .ssh в домашнем каталоге пользователя.

Теперь необходимо добавить публичные SSH-ключи в файл authorized_keys пользователя git. К примеру, публичные ключи разработчиков (пользователей Git-репозитория) получены и находятся в каталоге /tmp.

$ cat /tmp/id_rsa.vasya.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.petya.pub >> ~/.ssh/authorized_keys

В данном случае для создания репозитория нового проекта один из пользователей репозитория должен создать «чистый» репозиторий на сервере. Каждый из пользователей (admin, vasya, petya) могут создать локальный репозиторий проекта следующим образом:

$ git clone git@gitserver:/home/git/project.git

Можно ограничить пользователя git возможностью работы только с Git-репозиторием (выполнение git-команд) с помощью ограниченного shell (git-shell), который устанавливается вместе с Git. Для этого необходимо отредактировать /etc/passwd и задать git-shell вместо bash или csh в качестве shell, используемого для доступа к серверу для пользователя git:

git:x:1000:1000::/home/git:/usr/bin/git-shell

21

Методические указания к выполнению лабораторных работ

2.2.3НАСТРОЙКА ДОСТУПА К GIT-СЕРВЕРУ С ИСПОЛЬЗОВАНИЕМ GITOSIS

Gitosis — набор скриптов для управления файлом authorized_keys и организации простого контроля доступа к репозиторию. Для управления доступом к репозиторию используется специальный Gitрепозиторий.

Для установки Gitosis требуется наличие установленных pythonsetuptools:

$ aptitude install python-setuptools

Клонируем и устанавливаем Gitosis с главного сайта проекта: $ git clone git://eagain.net/gitosis.git

$ cd gitosis

$ sudo python setup.py install

Gitosis создает хранилище репозиториев в каталоге /home/git. Gitosis автоматически управляет публичными ключами для дос-

тупа к репозиторию, поэтому переместим файл authorized_keys, ключи разработчиков добавим позже:

$

mv

/home/git/.ssh/authorized_keys

/home/git/.ssh/ak.bak

Далее необходимо инициализировать Gitosis с вашим публичным ключом (если он не на сервере, скопируйте его сюда):

$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub Initialized empty Git repository in /home/git/gitosis-

admin.git/	existing	Git	repository	in
Reinitialized

/home/git/gitosis-admin.git/

Это позволит пользователю (с указанным публичным ключом) вносить изменения в главный Git-репозиторий для настройки Gitosis. Необходимо настроить возможность выполнения post-update скрипта:

$

sudo

chmod

755

/home/git/gitosis-

admin.git/hooks/post-update

Если все верно настроено, можно получить репозиторий управления доступом к Git-серверу, использую ssh-доступ пользователя, для которого был добавлен публичный ключ при инициализации Gitosis.

# on your local computer

$ git clone git@gitserver:gitosis-admin.git

После копирования репозитория, появится каталог gitosis-admin. Файл gitosis.conf используется для определения пользователей, репозиториев проектов и прав доступа к ним. Директория keydir используется для хранения публичных ключей всех пользователей, которые имеют какой-либо доступ к репозиторию.

Изначально файл gitosis.conf содержит информацию только для проекта gitosis-admin:

$ cat gitosis.conf [gitosis]

22

Инженерия программного обеспечения

[group gitosis-admin] writable = gitosis-admin members = git

Т.е. git – единственный пользователь, который имеет доступ к репозиторию проекта gitosis-admin.

К примеру, добавим новый проект. Создадим новый раздел mobile, в котором перечислим разработчиков команды mobile и проектов, к которым разработчики должны иметь доступ. Создадим новый проект iphone_project. Изменим содержимое файла gitosis.conf:

[group mobile]

writable = iphone_project members = git

После внесения изменений в проект gitosis-admin, необходимо зафиксировать изменения и отправить изменения на сервер:

$ git commit -am 'add iphone_project and mobile group' [master]: created 8962da8: "changed name"

1 files changed, 4 insertions(+), 0 deletions(-) $ git push

Counting objects: 5, done. Compressing objects: 100% (2/2), done.

Writing objects: 100% (3/3), 272 bytes, done. Total 3 (delta 1), reused 0 (delta 0)

To git@gitserver:/home/git/gitosis-admin.git fb27aec..8962da8 master -> master

Можно начать работу с новым проектом iphone_project, указав его как удаленный репозиторий для локальной копии проекта. Нет необходимости в создании «чистой» копии репозитория для новых проектов на сервере — Gitosis создает их автоматически при первой отправке изменений в проект (push).

$	git	remote		add	origin
git@gitserver:iphone_project.git
$ git push origin master			Git	repository	in
Initialized		empty
/home/git/iphone_project.git/
Counting objects: 3, done.
Writing objects: 100% (3/3), 230 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@gitserver:iphone_project.git
	* [new branch]	master -> master

Чтобы предоставить доступ другим пользователям к проекту, необходимо добавить их публичные ключи в каталог keydir.

$ cp /tmp/id_rsa.vasya.pub keydir/vasya.pub $ cp /tmp/id_rsa.petya.pub keydir/petya.pub

После этого можно добавить новых пользователей в группу mobile для предоставления доступа (read/write) к проекту iphone_project:

[group mobile]

writable = iphone_project

23

Методические указания к выполнению лабораторных работ

members = git vasya petya

Для предоставления пользователю vasya доступа к проекту только на чтения, необходимо изменить gitosis.conf:

[group mobile]

writable = iphone_project members = git petya

[group mobile_ro] readonly = iphone_project members = vasya

Создадим группу mobile, наследуя всех участников группы mobile_committers:

[group mobile_committers] members = git vasya petya

[group mobile]

writable = iphone_project members = @mobile_committers

Желательно также добавить loglevel=DEBUG в разделе [gitosis].

2.2.4 НАСТРОЙКА ПУБЛИЧНОГО ДОСТУПА К РЕПОЗИТОРИЮ С ИСПОЛЬЗОВА-

НИЕМ GITWEB

При неоходимости предоставить анонимный доступ на чтение к Git-репозиторию проекта, самый простой способ — запустить вебсервер, указав в качестве document root директорию, содержащую хранилище Git-репозиториев проектов. Для этого можно использовать любой веб-сервер, рассмотрим на примере Apache.

Итак, хранилище репозиториев находится в каталоге /home/git и сервер Apache на машине должен быть запущен.

Для начала активируем post-update hook: $ cd project.git

$ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update

post-update hook выглядит следующим образом: $ cat .git/hooks/post-update

#!/bin/sh

exec git-update-server-info

Теперь при отправке изменений на сервер по SSH, Git запустит данную команду, чтобы обновить файлы, необходимые для выполнения команды fetch по HTTP.

Далее необходимо добавить VirtualHost в конфигурационном файле Apache-сервера, указав document root, где находится корневая директория Git-проектов.

<VirtualHost *:80> ServerName git.gitserver DocumentRoot /home/git <Directory /home/git/>

24

Инженерия программного обеспечения

Order allow,deny allow from all

</Directory>

</VirtualHost>

Необходимо также предоставить группе www-data доступ к директории /home/git, чтобы веб-сервер имел доступ на чтение каталога с репозиториями.

$ chgrp -R www-data /home/git

После перезапуска сервера Apache, появится возможность клонировать репозитории из указанного хранилища репозиториев следующим образом:

$ git clone http://git.gitserver/project.git

После того как настроен read/write и read-only доступ к проекту, настроим веб-интерфейс для отображения репозитория с использовани-

ем GitWeb.

Для начала, необходимо получить исходный код GitWeb и сгенерировать CGI-скрипт:

$ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git/

$ make GITWEB_PROJECTROOT="/home/git" \ prefix=/usr gitweb/gitweb.cgi

$ sudo cp -Rf gitweb /var/www/

Переменная GITWEB_PROJECTROOT должна указывать на директорию, где необходимо искать Git-репозитории проектов.

Необходимо, чтобы Apache использовал CGI для этого скрипта. Добавим VirtualHost в конфигурационный файл Apache:

<VirtualHost *:80> ServerName gitserver

DocumentRoot /var/www/gitweb <Directory /var/www/gitweb>

Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch

AllowOverride All order allow,deny Allow from all

AddHandler cgi-script cgi DirectoryIndex gitweb.cgi

</Directory>

</VirtualHost>

Теперь по адресу http://gitserver/ возможно просмотреть репозиторий проекта, а указывая http://git.gitserver как путь к репозиторию, можно копировать репозиторий по HTTP.

2.2.5 ИНТЕГРАЦИЯ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ REDMINE С GIT

Для подключения репозитория проекта заходим в настройки проекта, переходим на закладку «Репозиторий», выбираем git и указываем

25

Методические указания к выполнению лабораторных работ

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

Существует возможность привязывать изменения в репозитории к определенным задачам, а также автоматическое изменение статуса задач при выполнении определенных коммитов в репозитории проекта.

2.3 Порядок выполнения работы

1.Установить и настроить Git (команда $ git config).

2.Каждая команда создает Git-сервер с главным репозиторием своего проекта и помещает туда исходный код проекта (в качестве примера использовать курсовой проект по объектноориентированному программированию).

3.Настроить доступ к Git-репозиторию для каждого члена команды с использованием Gitosis.

4.Настроить публичный доступ на чтение к репозиторию и вебинтерфейс с использованием Gitweb.

5.Изучить стандартную сессию работы с Git-репозиторием (по материалам лекции 5).

6.Запустить Redmine.

7.Создать в Redmine свой проект и настроить для него репозиторий.

2.4 Задания для самостоятельной работы

Разобраться с настройкой шаблонов коммитов для автоматического изменения статуса задач (в разделе «Администрирование»).

2.5Содержимое отчета

–описание процесса создания Git-репозитория и предоставления доступа к нему (используя два способа, указанных в задании); привести результаты выполнения команд;

–содержимое конфигурационных файлов;

–сессия работы (своя для каждого члена команды) с результатами выполнения команд;

–результаты настройки репозитория для проекта в Redmine в виде скриншотов;

–процесс настройки шаблонов коммитов для связи с задачами проекта и примеры, отображающие результат настройки.

26

Инженерия программного обеспечения

2.6 Контрольные вопросы

1.Назначение систем управления версиями документов.

2.Существующие методики организации совместной работы. Какая из них используется в git?

3.Архитектурные особенности систем управления версиями. Архитектурные особенности git.

4.Сессия работы с git-репозиторием.

5.Возможно ли в git осуществить переключение в другую ветку без фиксации изменений в текущую?

27

Методические указания к выполнению лабораторных работ

3Лабораторная работа №3 Инструменты сборки проектов

3.1 Цель работы

Изучение цикла сборки проекта. Практическое применение инструмента сборки maven. Добавление фазы тестирования в жизненный цикл проекта. Написание модульных тестов с использованием библио-

теки JUnit.

3.2 Теоретические сведения

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

Процесс создания готового дистрибутива ПО также требует автоматизации, т.к. существует огромное количество форматов создаваемых пакетов в зависимости от ОС, платформы, дистрибутива Linux и т.д.

Системы сборки как раз и предназначены для автоматизации вышеуказанных процессов. Примеры подобных систем – утилита make,

набор утилит Autotools (autoconf, automake, libtool, gnulib), qmake, bakefile, Cmake, ant, Gant, maven.

Мaven – не только инструмент сборки, это инструмент декларативного описания проекта. Maven вводит понятие объектной модели проекта (Project Object Model – POM). Вы задаете описание вашего проекта, его уникальные координаты, определяете перечень зависимостей и другие атрибуты.

Использование подобной модели имеет следующие преимущест-

ва.

1. Управление зависимостями.

Поскольку каждому проекту ставятся в соответствие уникальные координаты (groupId:artifactId:version), то эти же координаты используются для определения зависимостей.

2. Удаленные репозитории.

Координаты, определяемые в POM-модели, используются для индексирования и поиска нужных артефактов в maven-репозиториях.

28

Инженерия программного обеспечения

3. Стандартизация цикла сборки проекта.

Плагины maven (plugins) реализуют последовательность действий для различных фаз цикла сборки и организуют сборку проекта в соответствии с его описанием (тип проекта и др.) и настройками конфигурационных переменных для плагинов, определенными в POM-модели проекта.

4. Интеграция с различными средами разработки.

Среды разработки (Eclipse, NetBeans, and IntelliJ) создают свои собственные файлы проектов, в которых хранят информацию о проекте, причем для разных IDE эти файлы разные. Maven стандартизирует описание проекта и позволяет сгенерировать файлы проекта для той иной среды разработки опять же на основе модели проекта.

5. Простой поиск и загрузка требуемых артефактов. Возможность автоматического поиска и загрузки нужных биб-

лиотек-артефактов из удаленных репозиториев благодаря уникальным координатам артефакта, а также существует возможность организации собственного репозитория артефактов и настройки репозиториев для проекта.

3.3Порядок выполнения работы

3.3.1ОРГАНИЗАЦИЯ СБОРКИ МНОГОМОДУЛЬНОГО ПРОЕКТА

1. Установить пакет maven2

Для ОС Ubuntu: $> aptitude install maven2.

Установка maven2 для ОС Fedora требует несколько больших усилий, т.к. менеджер пакетов yum устанавливает старую версию 2.0.4.

Разархивируйте архив apache-maven-2.0.9-bin.tar.bz2 в домашний каталог и переименуйте директорию в maven2:

$> tar xjvf apache-maven-2.0.9-bin.tar.bz2 $> mv apache-maven-2.0.9 maven2

Чтобы установить переменные окружения для maven2, добавьте следующие строки export PATH=$PATH:$HOME/maven2/bin в файл /etc/profile.d/mvn.sh (gedit /etc/profile.d/mvn.sh) и выполните команду:

$> source /etc/profile.d/mvn.sh

Проверьте правильность установки и настройки maven командой $> mvn --version

2.Настроить репозиторий артефактов (локальный) для maven. Поскольку нам нужны глобальные настройки репозитория (для всех проектов), то редактируем файл /путь/к/maven2/settings.xml (аналогично репозиторий можно было прописать в pom.xml файле конкретного проекта). В раз-

деле <profiles></profiles> добавляем:

<profile>

<id>stuRepo</id>

29

Методические указания к выполнению лабораторных работ

<repositories>

<repository>

<id>main</id>

<name>StuRepository</name>

<url>http://devel.stu.cn.ua:8081/artifactory/repo/

</url>

<layout>default</layout>

</repository>

<repository>

<id>snapshots</id>

<url>http://devel.stu.cn.ua:8081/artifactory/repo/

</url>

<releases>

<enabled>false</enabled>

</releases>

</repository>

</repositories>

<pluginRepositories>

<pluginRepository>

<id>central</id>

<url>http://devel.stu.cn.ua:8081/artifactory/plugi ns-releases/</url>

<snapshots>

<enabled>false</enabled>

</snapshots>

</pluginRepository>

<pluginRepository>

<id>snapshots</id>

<url>http://devel.stu.cn.ua:8081/artifactory/plugi ns-snapshots/</url>

<releases>

<enabled>false</enabled>

</releases>

</pluginRepository>

</pluginRepositories>

</profile>

И активируем профайл:

<activeProfiles>

<activeProfile>stuRepo</activeProfile>

</activeProfiles>

3.Создадим многомодульный проект — веб-приложение, предоставляющее информацию о гостиницах. Приложение состоит из двух модулей:

–модуль бизнес-логики: business-logic.jar;

–модуль веб-приложения: hotelweb.war.

В каталоге проекта создадим модуль бизнес-логики приложения. Используя плагин archetype, создадим «пустой» maven-проект для модуля бизнес-логики:

mvn archetype:generate

30