github化、dotfile script化、devcontainer化の力で新規WSL環境で爆速で趣味開発を再開できた
概要
普段の開発から以下の施策を進めていました。
- コードのgithub管理化
- dotfilesのgithub上で管理されたscript化
- 個々のrepositoryのdevcontainer化
以上の施策のおかげで、新規WSL環境で開発を始めるとき、思った以上にスムーズに開発可能な状態に戻れたので感動を共有します。
新WSL開発を再開するために行った手順(時系列順)
-
秘密鍵/公開鍵ペアを作成し、githubに登録
手元環境初期化用dotfilesをgithubにfetchしに行くためです。
ssh-keygenで鍵ペアを作成し、browser経由で鍵を登録しました -
git から 自分のdotfiles repo をcloneしてくる
dotfilesの中に、環境初期化スクリプトが入っているのでそれを実行するためです。
- zshを手でインストール
dotfilesに組み込み忘れていました... 無駄な手順が増えてしまって悲しい。チャート改善点です。
自分好みの環境に変えます。このinstall.shでは以下のことを行っています。
- oh-my-zshのインストール
- 自作 oh-my-zsh テーマの適用
- オレオレ .zshrc の配置
- git configの初期化
- gh コマンドのインストール
github を操作するコマンドです
初手で行えばよかったな...
何につけても必要かつ WSLの直環境で必ず用いるコマンドなのでインストールします。
-
gh auth loginの実行
gh コマンドでgithubにログインします。 -
gh repo clone <開発したいrepository>を実行
旧環境ではコードソースは全てgithubにuploadしていました。そこで、新規環境でもgithubからcloneすることで容易にコードを引き継げます。
ghコマンドでは、自分のレポジトリならば、レポジトリ名だけでlocalにcloneすることができます。
-
code .を実行し、remote containerとして開く
remote container機能については弊記事VSCode のリモートコンテナ機能を用いて、あるリポジトリ専用の環境を開発者間で統一するをご覧ください。
開発したいrepositoryはdevcontainer化されていましたので、vscodeで開き、devcontainerとして開きます。
docker containerが立ち上がり、開発に必要な諸々のコマンド、python packageなどが既にインストールされた状態で開発を始めることができます
以上 8 手順で開発体制を整えることができました。
感想
dotfilesにinstall.shを配置した便利さもさることながら、普段の開発をdev-container化してlocalに入れるべき設定をなるべく薄くしていたことが、初回設定を容易にしたんだと思うんですよね。
毎回場当たり的に初回セットアップ手順を行っていくのではなく、開発環境 as a codeの精神でなるべくスクリプト化していくことでハードの移行をスムーズに行うことができました。
コード類は完全にgithub上で管理しているので、容易に環境を吹っ飛ばして作り直しできるのもハード移行の精神的負荷を軽くしてくれました。
皆様もこのスタイルを採用したら新規環境の構築・旧環境の破壊再構築が楽になるかもしれないと思って今の興奮を共有させていただきました。
まとめ
- コードのgithub管理化
- dotfilesのgithub上で管理されたscript化
- 個々のrepositoryのdevcontainer化
を実施していたおかげで、スムーズに開発環境を再構築できた。
Discussion