🎏

Glitchの手軽さを維持しつつも検証環境を用意するTips

2020/11/13に公開

Glitchでのアプリ開発は手軽にできる反面、手軽過ぎるため検証不十分なコードが本番環境に混入してしまうリスクもあります。
とはいえ、やはりGlitchの最大の魅力はその手軽さ・アジリティーにありますので、それらを最大限に活かしながら本番環境とは別に検証用のGlitch環境を利用するTipsのご紹介です。

結論

Glitchの中身はgitのリポジトリです。そのため、以下の流れで検証・本番環境を管理することができます。

  1. 検証用のプロジェクト(以降pj-stag)を用意しアプリの実装・検証を行う
  2. 検証用のプロジェクトをRemixして本番用のプロジェクト(以降pj-prod)として複製する
  3. pj-prodでpj-stagのgit URLをgit remote addして登録
  4. 以降機能追加や修正はすべてpj-stagで行い、確認できたらpj-prodでgit pullして取り込む

こうすることで、検証が完了したコードだけを本番に反映させることができます。また、.envに記載している環境依存情報はそれぞれのプロジェクトで独立して管理することができるため、たとえばトークンなどのクレデンシャル情報はそれぞれのプロジェクトで維持することができます。

なお、この手順ではGlitchの標準機能を介さずにgitを直接実行しています。そのため、例えば検証環境ではなく本番環境を直接編集してしまった場合の復旧対処には、gitの理解と操作が必要となりますので、ご注意ください。
そのため、ある程度の人数規模でメンテナンスするレベルのプロジェクトであったり、レビュー承認が必要なプロジェクトの場合には、今回ご紹介する方法ではなく、GitHubとGlitchを連携させる運用をおすすめします。
今回の手順はあくまでGlitchの手軽さアジリティーを保ちつつも、本番環境と検証環境を分けて運用・管理するためのTipsのご紹介となります。

前置きが長くなりましたが、以下に具体的な流れを記します。

Glitchプロジェクト準備

Glitch上に検証用となるプロジェクトを作成します。Glitchの右上にあるNew Projectからhello-expressをクリックします。

わかりやすくするため、プロジェクト名をpj-stagに変更します。

アプリケーションの実装&検証

アプリケーションの実装と検証を行います。今回は割愛します。

本番用のREMIX

左上のプロジェクト名をクリックしたら、Remix Projectをクリックして複製します。
これで本番用のプロジェクトができました。

わかりやすくするため、プロジェクト名をpj-prodに変更します。

Gitで紐付け

pj-stagでToolsImport and Exportをクリックし、Your project's Git URL:にあるCopyをクリックして、pj-stagのGit URLをコピーします。

次にpj-prod側で、toolsTerminalをクリックします。

念の為、現在の設定を確認します。git remote -vを実行して、何も表示されなければOKです。

pj-stagをリモートリポジトリに登録します。
git remote add origin [pj-stagのGit URL]と実行してください。

再度git remote -vを実行して、上流プロジェクトが登録されていることを確認します。

これでpj-stagとpj-prodの紐付けができました。

本番環境への反映

pj-stagで行った修正内容をpj-prodに反映する場合は、pj-prodのTerminalでgit pull origin masterと実行してください。
なお、Glitch上の表示に反映されるまで多少のタイムタグがありますが、即時反映させる場合はGlitchのターミナルでrefreshコマンドを実行してください。

これで、pj-stagで修正し、pj-prodに反映させるという流れでできました。

注意点

  1. Glitch上でのgit commitのタイミング
    Glitch上で任意の修正を行った場合、即時GitにCommitされるわけではなく、一定間隔でポーリングしているようです(またはRewind画面を表示させると更新される)。そのため、検証環境で修正してすぐに本番環境でpullしようとしても取り込まれないことがあります。
    Glitch上のGitに反映されたかどうかは、Terminalでgit logコマンドを実行するか、Tools→Rewindの画面で確認できます。

  2. git pushでのエラー回避
    今回の手順ではpj-prod側でgit pullして修正を取り込んでいますが、pj-stag側からgit pushする運用については、不可能ではないもののおすすめはしません。
    Glitch上のリポジトリはbareリポジトリではないため、pj-stagでマージ用のブランチを作成して、pushしてmergeといった流れをやるくらいなら、GitHubと連携させる運用をおすすめします。
    (別途記事公開予定)

  3. pj-prodを直接更新してしまった場合
    今回の手順では修正内容はpj-stag側からの一方通行を想定していますが、pj-prod側への修正を禁止することは現状できません。もしうっかりpj-prod側を修正してしまった場合は、GlitchのRewind機能は使わずにpj-stag側にgit remote addでpj-prod環境を登録して修正を取り込んで同期させることをおすすめします。
    (別途記事公開予定)

以上、Glitch上で手軽さを維持しつつも、検証環境を利用するためのTipsのご紹介でした。

Discussion