CLI ツールを導入した理由
目標は エンジニアがどのプロジェクトに入っても，同じ操作体験で開発できる こと
導入する前の問題は
- プロジェクト毎に作業の詳細が異なる
- 長い README を元に作業するものの再現性がない
- メンバ毎の秘伝のメモ帳が発展するが共有はされない
導入の経緯
- CLI ツールを作っているチームがいると聞く 👍
- Rust で作ろうと息巻く 😤
- ShellSpript で書く方針に変更 🤔
- ルーチンをひたすらコマンド化 🔥
- 昔作られた CLI ツールをプロジェクト内で発見 🤭
- 邪魔だったのでプロジェクトから削除 😗
- 他プロジェクトに展開 🔥
- CLI ツールを簡単に導入できるテンプレート作成 🎊
- 高機能化に対応するため Python で部分的な機能を書き始めた 🔥（← 今ここ）
何ができるか
プロジェクト用のコマンドを書くとまずいので，テンプレートから参照
$ uvcli
UniqueVision でプロジェクト開発を便利にするためのCLIツールの雛形
Commands:
General:
welcome 初めて開発する人向けの情報
init[ialize] [OPTIONS] 初期化する
cd [DIRECTORY] プロジェクト内のディレクトリに移動する
edit [FILE]... エディタでプロジェクトを開く
Containers:
build ビルドする
start 開始する
stop 終了する
process|ps [-s] 起動しているDockerサービス一覧を表示する
exec[ute] SERVICE COMMAND SERVICE_NAMEのコンテナで、COMMANDを実行する
shell SERVICE 対象のコンテナにシェルではいる。
restart SERVICE 特定のサービスを再起動する
log [-f] [SERVICE] ログを出力する
url SERVICE 指定したサービスへアクセスするURLを出力する
ディレクトリ構成
プロジェクト用のコマンドを書くとまずいので，テンプレートから参照
.
├── bin
│ └── uvcli
│
├── cli
│ ├── commands
│ │ ├── welcome.sh
│ │ └── ...
│ │
│ ├── completion
│ │ └── uvcli_cmdcomp.toml
│ │
│ ├── README.md
│ └── uvcli.sh
│
├── docker-compose.yml
└── README.md
実際の操作体験
インストール
git clone $YOUR_PROJECT
uvcli init
echo 'eval $(uvcli init -)' >> ~/.bash_profile
開発
# 開発開始
uvcli build
uvcli start
# 開発終了
uvcli stop
デプロイ
uvcli $REALM deploy
いや〜簡単ですね
補完機能
CLI を使うなら，補完機能は必須だと思っている
いいツールが見つからなかったので簡単に補完機能を用意できるツール cmdcomp を新規に設計
toml ファイルを書くことで補完機能の書き方を知らない人でも容易に補完機能を追加することができる！
[cmdcomp]
version = "0.1.0"
[app]
name = "uvcli"
[root.subcommands.welcome]
[root.subcommands.initialize]
alias = "init"
options = ["-"]
なぜ ShellScript で作ったのか？
実行速度，安全性，機能性，全てにわたって Rust が凌駕するでしょう...（当然）
しかし，Rust をどれだけの人が読み書きできるだろうか？ 5 年後にも同じことが言えるだろうか？
ShellScript を採用した理由は みんなが書けて， 5 年後もそう だからだ（だよね 😉 ）
高機能化について
高度な機能（あいまい検索，設定ファイルを元にした複雑な処理）が欲しい！
Python で複雑な機能を処理し ShellScript 内で呼ぶことにした
なぜ Rust で書かなかったのか？...clap v3 が正式リリースされてないからかな？
最後に
- みんなも CLI ツールを作ろう 🤩
- Shell Script は寿命が長いよ 😉
- Shell Script には限度があるよ 😉
- tcsh，fish には塩対応 🤫