Clever Geek Handbook

FutoIn CIDを使用した自動化の一環として、VCS / SCMを使用した多彩な作業

use cases







一部の現代のプログラマーには、Git以外のバージョン管理システムはありませんが、実際には、Subversionは依然として需要があり、Mercurialには熱心なサポーターがいます。 援軍のクイック検索 。







その結果、非モノプロジェクト企業のDevOpsは、非常に異なるシステムで作業を自動化する必要に直面しています。 同時に、それぞれに独自のニュアンスがあり、必然的に、最も不適切な瞬間に撮影するシナリオに隠れたエラーがあります。 たくさんの可能性ではなく、最小限の「柔軟性」を備えた予測可能な動作が必要です。







インターフェース



FutoIn CIDを紹介する記事では、さまざまなVCSの暗黙的な作業について既に説明しています。 バージョン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>]


分散型バージョン管理システムのイデオロギー的優位性に関するスローガンから離れると、裕福なプロジェクトの開発における最終結果は、クライアント側に追加のプラスを加えた同じクライアント/サーバーモデルになります。 2番目の明らかな点は、分散システムでのクライアントサーバーモデルの問題のない「エミュレーション」と、反対の実装の難しさです。 これが作業ロジックの理由です-サーバーとの強制的な暗黙的な同期。







これは一致するテーブルを意味します：







シド Git マーキュリアル 転覆
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



git archive | tar



hg archive --type files



+ .hg*



クリーンアップ 		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 **/*.orig



hg update --clean



svn revert -R .



cid vcs ismerged



git branch -r --merged HEAD



hg merge --preview



svn mergeinfo --show-revs eligible





それはすべての簡潔さで非常に明確なようです。 以下にのみ注意してください：







  1. SVNは、明示的な改訂指示なしのマージに依存しています-「何をしているのかを知る」。
  2. Hgにはブランチの削除はなく、ブックマークは松葉杖に似ています。
  3. もちろん、これらの3つのシステム上で光が一緒になったとしても、プラグインメカニズムを介して他のサポートを追加する機会があります。


いくつかの例



面倒なことのないすべての例：小さなコメント、一連のコマンドそのまま、そして視覚的な結果。







>準備作業



繰り返しますが、純粋なDebian Jessieを使用します。 Gitリポジトリを作成し、README.txtファイルとLICENSEファイルを追加して、2番目の開発ブランチを作成しましょう。 







 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


prepare







>ジョブストーリーNo. 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


case #1







>ジョブストーリーNo. 2：毎晩（コミットごと）、開発（リリース）ブランチを機能（開発）ブランチにマージして、矛盾を避け、プロセスが尊重されるようにする必要があります。



注：このワークフローは、イデオロギー的に正しい（および安全な）と見なされますが、リベースはより不毛で理解しやすいストーリーになります。







ブランチの準備： 







 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


case #2 prepare







 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


case #2







予想されるエラー-競合を明確に作成しましたが、タイプミスがあります-いいえ。 次のリリースで修正される予定です。







> Job Story No. 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


case #3







>ジョブストーリーNo. 4：一定の頻度で、ファイルを生成し、VCSに送信して完全な変更履歴を取得する



例：a）商用ブログまたはニュースサイトにファイルをダウンロードすると、Subversionの整合性と効率を高めるために特定の価値がありますSubversionは非常に適切になりますb） アクティブな攻撃のアドレスの絶えず更新されるブラックリストの例、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}"


case #4







>ジョブストーリーNo. 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}"


case #5

乱雑にならないように、npm / composer / bundlerファイルはサンプルに追加されていません。







おわりに



一般に、FutoIn CIDは技術的なプロセスを一切課しませんが、管理者、DevOps、さらにはコマンドラインの開発者の創造性のために、VCS / SCMへの単一の軽量インターフェースのみを提供します。







もちろん、インターフェースはまだ完全に落ち着いていません;後方互換性のある変更が可能です。 見つかった問題、提案、提案は大歓迎です。







More articles:


All Articles