Для некоторых современных программистов не существует другой системы контроля версий, кроме Git, но на практике Subversion по-прежнему востребована, и у Mercurial есть свои ярые сторонники.
Быстрый поиск в подкреплениях.
В результате DevOps неоднопроектных компаний сталкиваются с необходимостью автоматизировать работу с очень разными системами.
При этом каждый имеет свои нюансы и в сценариях неизбежно появляются скрытые ошибки, выскакивающие в самый неподходящий момент. Необходимо предсказуемое поведение с минимальной «гибкостью», а не пестрый букет возможностей.
Интерфейс
В статья встречаться ФутоИн C.I.D. Неявная работа с различными СВК уже была описана.В версии v0.7 был добавлен явный командный интерфейс и новый функционал для автоматизации создания и объединения ветвей: В общем сам интерфейс с комментариями ниже:
Если отступить от лозунгов об идеологическом превосходстве децентрализованных систем контроля версий, то итогом разработки любого успешного проекта остается все та же клиент-серверная модель с дополнительными преимуществами на стороне клиента.cid vcs checkout [<vcs_ref>] [--vcsRepo=<vcs_repo>] [--wcDir=<wc_dir>] cid vcs commit <commit_msg> [<commit_files>.] [--wcDir=<wc_dir>] cid vcs merge <vcs_ref> [--no-cleanup] [--wcDir=<wc_dir>] cid vcs branch <vcs_ref> [--wcDir=<wc_dir>] cid vcs delete <vcs_ref> [--vcsRepo=<vcs_repo>] [--cacheDir=<cache_dir>] [--wcDir=<wc_dir>] cid vcs export <vcs_ref> <dst_dir> [--vcsRepo=<vcs_repo>] [--cacheDir=<cache_dir>] [--wcDir=<wc_dir>] cid vcs tags [<tag_pattern>] [--vcsRepo=<vcs_repo>] [--cacheDir=<cache_dir>] [--wcDir=<wc_dir>] cid vcs branches [<branch_pattern>] [--vcsRepo=<vcs_repo>] [--cacheDir=<cache_dir>] [--wcDir=<wc_dir>] cid vcs reset [--wcDir=<wc_dir>] cid vcs ismerged <vcs_ref> [--wcDir=<wc_dir>]
Второй очевидный момент — беспроблемная «эмуляция» клиент-серверной модели в распределенных системах и сложность реализации обратной.
Именно это и определяет логику работы — обязательная неявная синхронизация с сервером.
Это подразумевает такую таблицу соответствия:
| CID | Гит | Меркуриальный | Подрывная деятельность |
|---|---|---|---|
cid vcs checkout |
git clone/fetch+ git checkout |
hg pull+ hg checkout |
svn checkout/switch |
cid vcs commit |
git commit+ git push |
hg commit+ hg push |
svn commit |
cid vcs merge |
git merge+ git push |
hg merge+ hg push |
svn merge+ svn commit |
cid vcs branch |
git checkout -b+ git push |
hg branch+ hg push |
svn copy |
cid vcs delete |
git branch -D+ git push -f --delete |
hg checkout+ hg commit --close-branch+ hg push |
svn remove |
cid vcs export |
git fetch/clone --mirror --depth=1+ git archive | tar |
hg archive --type files+ .
очистка |
svn export |
cid vcs tags |
git ls-remote |
hg tags |
svn ls {repo}/tags |
cid vcs branches |
git ls-remote |
hg branches |
svn ls {repo}/branches |
cid vcs reset |
git merge --abort+ git reset --hard |
hg update --clean+ hg purge -I **/*.
|
svn revert -R .
|
cid vcs ismerged |
git branch -r --merged HEAD |
hg merge --preview |
svn mergeinfo --show-revs eligible |
Стоит только отметить, что:
- SVN опирается на слияние без явной ссылки на версии - «знай, что делаешь».
- В Hg нет удаления веток, а закладки больше похожи на костыль.
- Конечно, хоть свет и сошёлся на этих трёх системах, через механизм плагинов можно добавить поддержку любой другой.
Некоторые примеры
Все примеры без лишних слов: небольшой комментарий, последовательность команд как есть и наглядный результат.> Подготовительные работы
Снова используем чистый Debian Jessie. Давайте создадим репозиторий Git, добавим файлы README.txt и LICENSE и создадим вторую ветку разработки.
sudo apt-get install -y python-pip
sudo pip install futoin-cid
VCS_REPO_DIR=${HOME}/repo
VCS_REPO=git:${VCS_REPO_DIR}
function prep_cache_dir() {
local repo=$1
local cache_dir=$(echo $repo | sed -e 's,[/:@],_,g')
[ -d $cache_dir ] && cid vcs reset --wcDir=$cache_dir 1>&2
echo $cache_dir
}
# set -x is too verbose
function cid() {
echo '$' cid "$@" 1>&2
$(which cid) "$@"
}
rm ${VCS_REPO_DIR} wc $(prep_cache_dir ${VCS_REPO}) -rf
cid tool exec git -- init --bare ${VCS_REPO_DIR}
cid vcs checkout --vcsRepo=${VCS_REPO} --wcDir=wc
# Commit All
echo 'Info' > wc/README.txt
cid vcs commit 'Initial commit' --wcDir=wc
# Commit specific file(s)
echo 'License' > wc/LICENSE
cid vcs commit 'Adding license' LICENSE --wcDir=wc
cid vcs branch develop --wcDir=wc
> История задания 1. Когда начинается работа над новой функцией, требуется автоматическое создание ветки для организации имени.
Примечание.
Предполагается, что разработчики не могут сами создавать ветки или им не рекомендуется это делать, и что трекер каким-то образом срабатывает. function on_feature_start() {
local repo="$1"
local feature="$2"
local cache_dir=$(prep_cache_dir $repo)
cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir
cid vcs branch feature-${feature} --wcDir=$cache_dir
}
function list_branches() {
# Remote case
cid vcs branches --vcsRepo=${VCS_REPO}
# Local case
cid vcs branches --wcDir=wc
}
on_feature_start "${VCS_REPO}" '123_one'
on_feature_start "${VCS_REPO}" '234_two'
list_branches
> История работы № 2: Каждую ночь (каждый коммит) ветку разработки (релиза) необходимо объединять с веткой функций (разработки), чтобы избежать несоответствий и обеспечить соответствие процесса.
Примечание: этот рабочий процесс в целом считается идеологически правильным [и безопасным], хотя rebase делает историю более стерильной и понятной.
Подготовка веток: cid vcs checkout develop --wcDir=wc
echo 'Info 2' > wc/README.txt
cid vcs commit 'Commit 2' --wcDir=wc
cid vcs checkout feature-234_two --wcDir=wc
echo 'Info 3' > wc/README.txt
cid vcs commit 'Conflict 3' --wcDir=wc
function sync_branches() {
local repo="$1"
local cache_dir=$(prep_cache_dir $repo)
local logfile=$(realpath $2)
cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir
pushd $cache_dir
# Release -> Develop
echo >$logfile
for b in $(cid vcs branches 'release*'); do
echo -n "Merging $b into develop: " >>$logfile
cid vcs merge $b && \
echo 'OK' >>$logfile || \
echo 'FAIL' >>$logfile
done
# Develop -> Feature
for b in $(cid vcs branches 'feature*'); do
echo -n "Merging develop into $b: " >>$logfile
cid vcs checkout $b && \
cid vcs merge develop && \
echo 'OK' >>$logfile || \
echo 'FAIL' >>$logfile
done
popd
}
sync_branches "${VCS_REPO}" merge.log
cat merge.log
Ошибка ожидал - мы намеренно создали конфликт, но в нем нет опечатки.
Будет исправлено в следующем релизе.
> История задания №3: после релиза удалить все включенные ветки функций, чтобы не засорять пространство имен
Примечание: для Hg и SVN в этом вообще нет ничего страшного, а вот для Git есть риск потери коммитов — поэтому желательно иметь зеркало для истории только для чтения.
function remove_merged() {
local repo="$1"
local cache_dir=$(prep_cache_dir $repo)
local logfile=$(realpath $2)
cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir
pushd $cache_dir
echo >$logfile
# Removed merged into develop
for b in $(cid vcs branches 'feature*'); do
if ! cid vcs ismerged $b; then
continue
fi
echo -n "Removing $b: " >>$logfile
cid vcs delete $b && \
echo 'OK' >>$logfile || \
echo 'FAIL' >>$logfile
done
popd
}
# Merge first branch
cid vcs checkout develop --wcDir=wc
cid vcs merge feature-123_one --wcDir=wc
# Try cleanup
remove_merged "${VCS_REPO}" delete.log
cat delete.log
> История задания № 4: с заданной частотой генерировать файлы и отправлять их в VCS, чтобы иметь полную историю изменений.
Примеры: а) загружаемые файлы в коммерческом блоге или новостном сайте имеют определенную ценность, Subversion становится чрезвычайно подходящей для повышения целостности и эффективности архивирования б) пример постоянно обновляемого черные списки адресов активных атак , без участия FutoIn CID. function update_file() {
local repo="$1"
local cache_dir=$(prep_cache_dir $repo)
cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir
pushd $cache_dir
date > Timestamp.txt
cid vcs commit 'Updated timestamp' Timestamp.txt
popd
}
update_file "${VCS_REPO}"
> История работы №5: каждую ночь вам необходимо обновлять зависимости во всех проектах, чтобы всегда использовать последние версии.
Примечание: может быть масса других вариантов автоматизированной обработки списка проектов.
function update_project_deps() {
local repo="$1"
local cache_dir=$(prep_cache_dir $repo)
cid vcs checkout develop --vcsRepo=$repo --wcDir=$cache_dir
pushd $cache_dir
date > Timestamp.txt
for t in $(cid tool detect); do
case $t in
npm*|composer*|bundler*) cid tool exec $t -- update ;;
esac
done
cid vcs commit 'Updated dependencies'
popd
}
update_project_deps "${VCS_REPO}"
Файлы npm/composer/bundler не были добавлены в пример, чтобы не загромождать его.
Заключение
В целом FutoIn CID не навязывает никаких технологических процессов, а лишь предоставляет единый облегченный интерфейс к VCS/SCM для творчества администратора, DevOps и даже разработчика в рамках командной строки.Конечно, интерфейс еще не до конца проработан; возможны обратно совместимые изменения.
Обнаруженные проблемы, предложения и пожелания добро пожаловать .
Теги: #futoin #git #hg #svn #Mercurial #subversion #DevOps #vcs #scm #разработка веб-сайтов #открытый исходный код #программирование #git #github
-
Октябрь Cms: Общедоступная Бета-Версия
19 Oct, 24
