😊 🐡 🏧 開発メタツール：FutoIn CID 😨 💶 👦🏿

use cases

最近では、 npm

、 composer

、 bundler

、 pip

、 maven

、 cargo

などのプロジェクト依存関係管理ツールに驚く人はほとんどいません。共通の欠点は、ランタイムを直接制御できないことです。この問題は、 nvm

、 php-build

、 rvm

、 virtualenv

、 sdkman

、 rustup

など、通常はBash / Zshで記述されたランタイムバージョンのグローバルな「マネージャー」によって解決されます。

次のレベルの「問題」は、普遍的な開発者が毎日まったく異なるテクノロジーを使用してプロジェクトに従事することから始まります。環境変数は混乱に変わり、シェルの起動には数秒かかる場合があります。必然的に、この動物園での作業における国内の間違いが始まります。

その後、継続的インテグレーションと配信は、混乱とよろめきを待ちます。そこでは、ツールをインストールして特定のバージョンをアクティブ化するタンバリンを使用した手動ダンスは完全に歓迎されませんが、理想的には、使用されている技術から可能な限り抽象化し、プロセスをプリミティブなニュートラルなコマンドにもたらすことが必要です：リリースの準備、zegate、ダウンロード、準備、ビルド、パック、レイアウト、チェック、承認（署名）、ロールアウト。

ここでは、ツールが自らを頼み、既存のテクノロジーの上で統一的に機能し、

これは、 FutoIn CID（FutoIn Continuous Integration＆Deliveryツール）を表します。

FutoIn CIDの哲学

特別なプロジェクトを使用して、それらを置き換えません。
構成せずに作業し、使用されるテクノロジーを自動的に決定します。
プロジェクトの依存関係のインストールの詳細から開発者ユーザーを取り除きます。
ベアPython 2.7および3.xでも動作します
CIDを構成し、デフォルトでコマンドをオーバーライドする機能を残します。
別のFTN16仕様により、代替実装が可能です。
すべての一般的なオペレーティングシステムと無制限の開発ツールのサポート。
特定のツールとその機能からの完全な抽象化。アプリケーションの種類ごとのツールの区分のみ：アセンブリ、テスト、バージョン管理システム、リリース管理システム、ランタイム、データ移行など。
余りにも自由なツールの強制的な統合と制限（たとえば、ブランチとタグに関するSubversion）。
状態全体は、構成オプション、展開環境、およびコマンドラインパラメーターの動的な値を完全に反映するツリー構造に格納されます。

基本操作

cid tag

-リリースのためのコードzagegitを準備します。
cid prepare

クリーンビルド用のコードを取得して準備し、すべての依存関係をインストールします。
cid build

プロジェクトをビルドします。
cid package

-バイナリアーティファクトを準備します。
cid check

展開を必要としないテストを実行します。
cid promote

バイナリアーティファクトをRMSに送信するか、より早く進めます

別のプールにロードされます。
cid deploy

バイナリアーティファクト、VCSタグ、またはブランチからデプロイします。
cid run

「エントリポイント」、特定のエントリポイント、または名前付きコマンドを設定してプロジェクトを開始します。
cid ci_build

-CIサーバーで実行promote

、1つのボトルでprepare

、 build

、 package

、およびpromote

します。
cid tool (install|uninstall|update|test|env)

-ツールを管理するためのインターフェース。
cid tool (prepare|build|check|package|migrate)

-特定のツールの標準操作を呼び出します。
cid tool (list|describe)

-サポートされるツールのリストと詳細な説明。
cid init

- futoin.json

構成futoin.json

初期化。

いくつかの実際のアクション

すべてが処女の浮浪者ボックスdebian/jessie64

ます。

1. APTベースのディストリビューションの例に基づいてディストリビューションをインストールします（Debian、Ubuntu、およびその他のフォーク）。

 sudo apt-get install -y python-pip sudo pip install futoin-cid #   RMS mkdir -p ~/Releases/Builds ~/Releases/Prod

2. `sudo`

構成する

妄想と利便性のバランスを見つけるために、パスワードなしでパッケージのインストールのみを許可することが提案されています。詳細はREADMEをご覧ください。

場合によっては、ZuluのDockerおよびJRE / JDKには、署名検証キーと追加のリポジトリをインストールする機能が必要です。 sudo

のフレームワークに懸念がある場合、これはあなたの手で行うことはそれほど難しくありません。すべての実行可能コマンドが出力されます。

Vagrantの場合、デフォルトですべてを実行できます。

3. HelloWorldを収集してみましょう。

 cid ci_build master Builds --vcsRepo=git:https://github.com/laravel/quickstart-basic.git --rmsRepo=scp:${HOME}/Releases

ci_build_1

~~多くの手紙~~

ci_build_2

では、何が起こったのか見てみましょう。

 tar tJf ~/Releases/Builds/laravel-CI-*.txz --exclude="*/*/*"

 ./ ./composer.json ./storage/ ./vendor/ ./resources/ ./.package.checksums ./LICENSE.txt ./composer.lock ./database/ ./.env.example ./.env ./LICENSE.txt.gz ./node_modules/ ./artisan ./.gitattributes ./phpunit.xml ./tests/ ./gulpfile.js ./app/ ./gulpfile.js.gz ./config/ ./package.json ./public/ ./server.php ./composer.json.gz ./readme.md ./package.json.gz ./bootstrap/

展開の準備が整った完全なバイナリアーティファクトが表示されます。デフォルトでは、CIDは、見つかった.js、 .json、 .css、 .svg、および* .txtファイルのgzipバージョンを作成し、nginxのgzip_staticモジュールで使用します。

SHA-512ハッシュを含む.package.checksums

ファイルは、即席マニフェストとして作成されます。

注：プロジェクトルートのパックは、別の実装がない場合の標準アクションにすぎません。 たとえば、MavenまたはPuppet自体がアーティファクトを作成します

4. RMSを使用して展開する

 cid deploy Builds --rmsRepo=scp:${HOME}/Releases --deployDir=deploy

cid deploy rms

注：デフォルトでは、明示的に名前を指定しない限り、CID自体は選択されたプール内の展開用の最新のアーティファクトを検索します。 同じことがタグにも当てはまります。

もちろん、それほど深刻なプロジェクトではない単一のマシンにデプロイする場合は、このような手順をスキップして、VCSタグから直接デプロイできます。

5. VCSで直接展開する

この例にはタグがないため、プロジェクトのライブブランチを使用します。

 cid deploy vcsref master --vcsRepo=git:https://github.com/laravel/quickstart-basic.git --deployDir=deploy

cid deploy vcs 1

~~多くの手紙~~

cid deploy vcs 3

ブランチを変更せずに繰り返し、既にデプロイされたリビジョンに関する警告を受け取ります。タグとアーティファクトを使用しても同じです。

 cid deploy vcsref master --vcsRepo=git:https://github.com/laravel/quickstart-basic.git --deployDir=deploy

cid deploy vcs 3

リリース用のプロジェクトコードの準備の例

ローカルコピーから呼び出して、特定のバージョンを準備します。

 cid tag master 1.0.0

呼び出し時にローカルコピーを持たない、次のインクリメンタルバージョンのリリース。

 cid tag master --vcsRepo=git:user@somehost:project.git

標準アクション：リモートリポジトリとの同期、可能なすべてのメタデータファイルの更新、コミット、タグの作成。 CID自体のリリース例：

cid tag

プロジェクトは追加のプラグインを使用する場合があります。たとえば、CIDはソースコードとCHANGELOGのバージョンを更新します。

私たちは個々のツールを使用します

 rubyVer=2.3 cid tool exec ruby -- -e 'puts "Hello World!"'

cid tool exec ruby

ツールがまだインストールされていない場合は、必要なすべての操作が実行されます。この場合、RVMがインストールされ、次に現在のRuby 2.3がインストールされます。この場合、シェルの起動時にRVMは起動せず、標準環境変数は汚染されません。

ツール情報

 cid tool describe maven

cid tool describe maven

技術的な詳細

`futoin.json`

ファイル

悪名高いpackage.json

、 composer.json

、 Cargo.toml

などとの類推により、プロジェクトがルートにある場合、それはプロジェクトの説明になります。一般的なプロジェクト設定を設定できますが、ファイルの存在はオプションです。

CIDは、起動時に展開ルートフォルダーで展開環境の可能な設定を検索します。プロジェクト設定と環境設定（ .env

ノード）の両方を指定でき、アクティブユーザーのホームフォルダーと.env

の.env

ノードのみを指定できます。。

注：.envノードは類似物ではなく、「dotenv」ファイルを置き換えるものではありません。

有効な値は、 FTN16で詳細に文書化されています。

最も興味深いサイト：

actions

-標準操作タグ/準備/ビルド/パッケージ/チェックをオーバーライドまたは補足できます。
plugins

-追加のツールを追加できます。
tools

使用するtools

のリストと、オプションでそれらのバージョンをしっかりと指定できます。
- バージョン'*'
  
  およびtrue
  
  デフォルトバージョンが必要
- それ以外の場合、バージョンは{tool}Ver
  
  環境変数に直接移動し、グローバル状態.env.{tool}Ver
  
  ノードとしてプラグインで使用できます。
toolTune

各ツールを特に微調整する機能。詳細はcid tool describe {tool}

利用できます。
entryPoints

名前付きエントリポイントをentryPoints

ます。
persistent

プロジェクト内の読み取り/書き込みパスのリスト。特にウェブ向け。

プロジェクトルートにあるfutoin.json

ファイルの例：

 { "name": "example-package", "version": "0.4.2", "actions": { "package": [] }, "plugins": { "examplerelease": "some.project.specific.release", "examplehelper": "some.other.helpertool" }, "vcs": "git", "tools": { "examplerelease": true, "python": "*", "node": "stable", "gradle": "*" }, "toolTune" : { "gradle": { "package": "jar" } }, "rms": "scp", "rmsRepo": "rms@somehost", "rmsPool": "ReleaseBuilds", "entryPoints": { "app": { "tool": "python", "path": "app.py", "tune": {} } } }

展開のニュアンス

{.deployDir}は、特定のプロジェクトをデプロイするための条件付きルートフォルダーです。
{.deployDir} / persistent-読み書き可能ファイル用のストレージ領域。クラスタとは、ネットワークファイルシステム領域を指します。
{.deployDir} / current-現在のバージョンへのシンボリックリンク。
{.deployDir} / {version_dir}-特定のバージョンの最終配置：
- {artifact}-RMSからの拡張子のないパッケージの名前、
- {vcsref} _ {vcsrevision}-ブランチからデプロイされる場合、
- {vcstag}-タグからデプロイされる場合。
{.deployDir} / {version_dir} .tmp-処理中の一時フォルダー。
{.deployDir} / {version_dir}。{ext}-rmsモードで展開されたバイナリアーティファクトではありません。
{.deployDir} / vcs- vcsref

およびvcstag

でのリポジトリのローカルコピー。
{.deployDir} /。futoin-deploy.lock-ロックファイル、および誤って指定されたターゲットフォルダーを誤ってクリアすることによるセキュリティ機能。
他のすべてはクリーンアップされます。

ツールを追加するための勇気について少し

すべてのツールはいくつかのタイプに分けられます。 1つのツールをすぐに複数のツールに適用できます。将来的には、さらに増えるかもしれません。

SubTool

-ベース、自動検出、依存関係の決定、インストール、更新、削除のためのインターフェース。
BuildTool

アセンブリツールのベース（準備、ビルド、パッケージ）。
MigrationTool

移行ツールのベース（移行）。
RmsTool

-RMS（プロモーション）および内部APIのベース。
RunEnvTool

バージョンマネージャー（nvm、rvm、gvmなど）のベース。
RuntimeTool

実行ツールのベース。これらには、java、python、rubyなどが含まれます。
TestTool

テスト（チェック）をサポートするツールのベース。
VcsTool

-VCS（タグ）および内部APIのベース

補助的なニーズのために、ミックスインのセットがあり、その一部はすでにサブツールに含まれています。

現時点では何がありますか？

CentOSやDebianからArchLinuxやGentooまで、ほぼすべての一般的なLinuxディストリビューションがサポートされています。

実験的なmacOSサポートを追加しました。適切な機器はありません-テストの助けは大歓迎です。

概念実証として、 PHP 、 Python 、 RubyからGo 、 Rust 、 Scalaまで、さまざまなプログラミング言語と関連ツールがサポートされています。カスタムプラグインを拡張および追加する機能は、ほぼ無制限です。

Git 、 Mercurial、およびSubversionの 3つの異なるVCSもサポートされています。

まだ何ですか？

RMSサポートは原則として実装されます。テスト目的では、これまでのところscp

のみが機能しますが、Archiva、Artifactory、Nexusのメインスコープです。

単体テストのサポートはプロジェクトビルドツール（make、gradle、gruntなど）に依存していますが、結果のコレクションはまだ決定されていません。推奨事項も歓迎します。

暗号署名プロセスはまだ決定されていません。ユースケースの共通分母を分析して見つけることが必要です。

必要に応じて、* BSDサポートは最小限の労力で済みますが、.Netに重点を置いたWindowsサポートでは、代替の特別な実装が必要になる可能性が高くなります。

データ移行用のインターフェイスが提供されていますが、標準の実装はまだありません。

まとめると

怠laz、単調な大騒ぎの病理学的拒否、および自動化への情熱に駆られて、ほぼすべての可能な技術に対して一般化の概念が生まれました。特定のFutoIn CIDツールの形式の実装が追加されました。もちろん、実際には深刻な粉砕と走行が必要です。開発者の生活を簡素化することに加えて、DevOpsインフラストラクチャの自動化も遠くから見られます。

もちろん、これはさまざまなテクノロジーをサポートする最初のツールではありませんが、おそらくチューニングなしで機能し、生産性を向上させ、日常のエラーの数を減らすことができる最初のツールです。

プロジェクトへのリンク：

→ GitHub

→ Pythonパッケージインデックス

→ FTN16ドラフト

開発メタツール：FutoIn CID