UMGUM.COM (лучше) 

BitBucket + Git Workflow ( Простая пошаговая настройка Git-репозитория на сервере хранения "Atlassian BitBucket", ориентированная на некоторые положения методики управления данными. )

19 декабря 2018  (обновлено 25 апреля 2019)

Apps: "Atlassian BitBucket (Standalone) Server".

Задача: проработать простую пошаговую настройку Git-репозитория на сервере хранения "BitBucket", ориентированную на следующие основные положения методики управления данными ("workflow"):

1. Репозиторий используется для хранения любого дерева веток, но подразумевается наличие как минимум трёх: "master", "testing" и "develop";
2. В "develop" и ответвлениях "feature" ведётся разработка - с ними можно делать что угодно;
3. Ветка "testing" по правам доступа аналогична "develop" - но выгрузка в неё запускает автоматизацию процедур тестирования;
4. Выгрузка в "master" напрямую запрещена - только вливание из "testing" с предварительным "pull request"-ом, который должен быть одобрен руководителем - после чего запускаются автоматизированные процедуры публикации.

Процедура установки и настройки web-сервиса хранилища репозиториев "Atlassian BitBucket Server" изложена в инструкции на этом же сайте.


Создание проекта (группы) и Git-репозитория.

В современных web-сервисах, в частности "Atlassian BitBucket Server", создание группы репозиториев и Git-репозитория в таковой не представляет сложности и не требует особого описания - пара нажатий на кнопки, заполнение полей именований и описаний, и вот у нас есть место на сервере хранения, куда уже можно загружать данные.

Обращу внимание на неочевидную особенность именований сущностей группы ("проекта" в терминологии "BitBucket") репозиториев:

"project name" - это отображаемое условное наименование (например "My first progect") и его можно безвредно изменить в любой момент;
"project key"  - это уникальный идентификатор группы (например "MY-PROJ-01") и его крайне нежелательно изменять в последствии, так как только через него возможна идентификация "проекта" в процедурах автоматизации.

В дальнейшем URI для доступа (через web-интерфейс SCM) к созданному репозиторию в группе таковых будет выглядеть так:

https://bitbucket.example.net/scm/project_key/repo.git

Настройки группы репозиториев (проекта).

Задаём разрешения доступа к группе репозиториев (эта политика распространяется на всю группу, но может быть переопределена):

Project -> Project settings -> Project permissions:
  Public access: false
  User access: user-one, user-two
  Group access: group-dev

Установка требования проверки запросов на запись в "master".

В настройках группы ("проекта" в терминологии "BitBucket") репозиториев (эта политика принудительно распространяется по иерархии ниже) или конкретного репозитория добавим запретительное правило доступа к ветке "master", указав отвергать все изменения без предварительного "pull request", а также запретив её удалять:

Project/Repository settings -> Branch permissions -> Add a branch permission:
  Branch name: master
  Restrictions: prevent changes without a pull request
  Restrictions: prevent deletion

В настройках группы репозиториев (эта политика принудительно распространяется на по иерархии ниже) или конкретного репозитория укажем пользователей, которые в обязательном порядке должны будут проводить "review" кода и одобрение такового при поступающих "pull request":

Project/Repository settings -> Default reviewers -> Add default reviewers:
  Source branch: Any branch            - неважен источник;
  Target branch: master                - все загрузки в "master" должны пройти проверку и получить одобрение;
  Default reviewers: teamlead, manager - пользователи, проводящие проверку;
  Approvals required: 2                - минимум два пользователя должны одобрить загрузку.

"Default reviewers" называются так потому, что это перечень инспекторов, которые автоматически будут привлечены к задаче одобрения процедуры, вне зависимости от желания вносящего изменения. Кроме того, при запросе на внесение изменений посредством "pull request" можно явно указать другого пользователя в качестве дополнительного проверяющего.

Теперь, при попытке сделать выгрузку (push) напрямую в "master" мы получим отказ:

$ git clone --branch master https://bitbucket.example.net/scm/group/repo.git
$ cd ./repo && vi ./probe.txt && $ git add --all && $ git commit -m "Probe push to master"
$ git push -u origin master

....
remote: Branch refs/heads/master can only be modified through pull requests.
remote: Check your branch permissions configuration with the project administrator.
....
To https://bitbucket.example.net/scm/group/repo.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://bitbucket.example.net/scm/group/repo.git'

Индивидуальные настройки репозитория хранения.

Сразу после загрузки данных в свежий Git-репозиторий есть смысл произвести некоторые настройки для удобства его дальнейшей эксплуатации.

Заранее создаём ветви "testing" и "develop" (предполагая, что первичная загрузка была в "master"):

Project -> Repository -> Create branch:
  Branch type: custom
  Branch from: master
  Branch name: testing

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

Project -> Repository -> Repository settings -> Repository details:
  Default branch: "develop"
  Allow forks: false
  Allow LFS: false

Опционально задаём разрешения доступа к репозиторию или проверяем и переопределяем их при необходимости, если они заданы на уровне группы репозиториев ("проекта" в терминологии "BitBucket"):

Project -> Repository -> Repository settings -> Repository permissions:
  Public access: false
  User access: user-one, user-two
  Group access: group-dev

Пример очерёдности процедур работы с Git-репозиториями "BitBucket".

Запрашиваем из репозитория хранения актуальное содержимое ветви разработки и явно переключаемся в таковую:

$ git clone https://bitbucket.example.net/scm/group/repo.git
$ cd ./repo
$ git branch
$ git checkout develop

Вносим изменения в файлы, сверяем и фиксируем их в ветви "develop":

$ vi ./probe.txt
$ git status
$ git add --all
$ git commit -m "Probe Commit"
$ git log

Выгружаем в репозиторий хранения наработки ветви "develop", воспользовавшись тем же адресом (web-интерфейс SCM) и протоколом (HTTPS), что и при предыдущей загрузке (обычно эти параметры автоматически фиксируются Git-клиентом в конфигурационном файле ".git/config" локального репозитория):

$ git push -u origin develop

Username for 'https://bitbucket.example.net': user-one
Password for 'https://user-one@bitbucket.example.net':
....
remote:
To https://bitbucket.example.net/scm/group/repo.git
  761ce6c..c2d33f3  develop -> develop
Branch 'develop' set up to track remote branch 'develop' from 'origin'.

После успешной фиксации изменений в ветке разработке переходим в ветку "testing" локального репозитория:

$ git fetch https://bitbucket.example.net/scm/group/repo.git testing
$ git checkout testing

Вливаем в ветку "testing" отличия, накопившиеся в ветке "develop":

$ git merge develop

Fast-forward
./probe.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

$ git status
$ git diff
$ git log

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

$ git push ssh://git@bitbucket.example.net:7999/group/repo.git testing

В соответствии с логикой построения нашей схемы на событие выгрузки в "testing" должны сработать предусмотренные процедуры автоматизированного тестирования (разберём их в отдельной заметке).

После того, как удостоверимся, что внесённые в "testing" изменения ничего не сломали, идём в web-интерфейс "BitBucket" и создаём запрос "pull request" на вливание изменений из ветки "testing" в "master":

Repository -> Pull requests -> Create pull request:
  Source: testing
  Destination: master

Далее всё просто и очевидно - проверяющие проверяют, одобряют и отдают команду принять вливание изменений.

В соответствие с логикой построения нашей схемы на событие выгрузки в "master" должна сработать автоматизация публикации, которая будет рассмотрена в отдельной публикации.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )