序文
最近、Angularの研究では、いくつかの基本的な構文はほぼ学習され、新しいコードリポジトリ上のgithubで、バックエンドアプリケーションのテンプレートを構築するng-zorroを使用する準備ができて、あなたが直接使用することができます将来的にいくつかの小さなことを書くのは簡単です。フロントエンドのプロジェクトは、主なものは、実際に見ることができるようにすることですので、デプロイする場所を見つけることを検討し、自分のブログはgithubページにデプロイされ、このプロジェクトは単なる静的なウェブサイトですので、ここでもgithubページを使用することを選択し
同時に、プロジェクトのリリースを考えると、githubのページの使用は、このステップをサーバーへのコピーファイルを省略するために役立っているが、まだ手動でプロジェクトのリリースを完了するには、独自のコマンドをノックする必要があるため、プロセスのリリースは非常に単一ですので、手順の展開の自動化を達成するためにgithubのアクションを介して自動化ツールの選択
コードリポジトリアドレス:ingos-admin
yuiter.com/ingos-adminプレビューしてください。
Step by Step
手動配備
サンプルAngularアプリケーションは、必要に応じて、このリンクをクリックしてビューに持ち上げます。）にジャンプすることができます、あなたは、Angular CLIを介して直接生成することができ、ここではの作成プロセスを実証するものではありません。
通常のフロントエンドプロジェクトリリースプロセスによると、リリースする必要がある場合、npmコマンドを使用してプロジェクトのパッケージ化を完了する必要があります。プロジェクト全体に関わるnpmコマンドは、プロジェクトのpackage.jsonファイルのscriptsノードを見ることで確認できます。
Angular CLIで作成したプロジェクトは、ng buildコマンドを使ってパッケージ化し、リリースすることができます。
ビルドコマンドが終了すると、プロジェクトのルートパスの下にあるdistフォルダ内のプロジェクトと同じ名前のフォルダがデプロイされるファイルになります。この時点で、自分のサーバーにデプロイする場合は、このフォルダをサーバーにコピーし、nginxなどのサーバー経由でファイルへのパスを指定するだけです。
同様に、githubのページにデプロイしたい場合は、githubのリポジトリにファイルを送信するだけで、githubが自動的にアプリケーションのデプロイを完了します。
git はデフォルトではコンパイル済みの dist フォルダを無視するので、コンパイル済みのファイルをリモートリポジトリにプッシュしたい場合は .gitignore ファイルを修正するか dist フォルダをサブツリー化してリモートサーバーにプッシュする必要があります。
# gh-pagesブランチを作成し、切り替える
git checkout -b gh-pages
# distフォルダからgh-pagesブランチにファイルを追加する
git add -f dist
# ローカルブランチにコミットする
git commit -m 'created gh-pages'
# リモートブランチにプッシュする
git subtree push --prefix dist origin gh-pages
もちろん、これはまだ少し面倒で、angularアプリの場合は、コミュニティが提供する angular-cli-ghpages プラグインを使うことで簡略化できます。
まず、デプロイするアプリケーションにnpm経由でプラグインをインストールする必要があります。
ng add angular-cli-ghpages
インストールが完了したら、ng deployコマンドでデプロイします。 このプラグインは自動的にパッケージ化されたファイルをgithubに公開し、githubページに表示されるサイトとしてgh-pagesブランチを作成します。
ng deploy --base-href=/ingos-admin/
angularのルーティングについて勉強したときにも書きましたが、angularのアプリケーションでは、index.htmlファイルのbaseタグのhref属性がコンポーネントやテンプレート、モジュールファイルなどの静的ファイルのベースパスのアドレスになるようにフレームワークが設定します。 https://<username>..io/<repositoryname>アプリケーションがgithubのページにデプロイされるとき、実際に対応するウェブサイトのアドレスは 、なので、ここでhrefを指定しないと、アプリケーションはルートパスでサイトに関連する静的ファイルを探しますが、最終的に見つけることは間違いなく不可能なので、href属性の値を倉庫の名前に調整する必要があります。
ご覧のように、パッケージによって生成されたindex.htmlファイルでは、プラグインはすでにbaseタグのhrefアドレスを変更するのに役立っています。今後、ウェブサイトを更新する必要があるときは、上記のコマンドを使ってgithubページに公開することができます。
ng deployコマンドを実行するたびにbase-hrefパラメータを追加する必要があるため、package.jsonファイルにスクリプトを追加しておけば、後でリリースする必要があるときにカスタムng deployコマンドを実行するだけで済みます。
{
"name": "ingos-admin",
"version": "1.0.0",
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"deploy": "ng deploy --base-href=/ingos-admin/",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e"
}
}
配備の自動化
上記の操作では、アプリケーションがgithubのページにデプロイされていますが、npmコマンドによる手動デプロイが必要なので、githubアクションによる自動デプロイを実現するように修正します。
github アクションは他のさまざまな自動化ツールと似ていて、特定の git イベントを指定することで自動タスクをトリガーすることができます。たとえば、サーバーの master ブランチにコードをプッシュしたときに自動的にリリースイベントをトリガーする必要があります。
リポジトリのアクションタブに新しいワークフローを追加するか、ローカルのコードルートに新しい.github/workflowsフォルダを作成してスクリプトを保存することができます。githubアクションはスクリプトの実行にyaml形式を使用するため、ここのコード形式には厳しい要件があります。各 yaml ファイルは個別のワークフローです
ここでは、githubのデフォルトのワークフローファイルを直接いじってデプロイを自動化しています。
- name: 現在のワークフロー構成名
- on: タスクがトリガーされたとき、ここでは github の master ブランチにコードをコミットしたときと PR をコミットしたときにトリガーされます。
- ワークフローは複数のジョブを含むことができますが、ここではbuildという名前のジョブのみです。
# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
push:
branches: [master]
pull_request:
branches: [master]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world!
# Runs a set of commands using the runners shell
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
ワークフローファイルの中で最も重要なのは、現在のワークフローが達成できることを示すジョブです。
- runs-on: 現在のジョブが実行される必要のあるシステム環境
- steps: ジョブを実行するために必要なステップ。
- env: 現在のジョブ実行に必要な様々な環境変数
- needs：複数のジョブが定義されている場合、デフォルトでは並行して実行されますが、job2が実行される前にjob1の実行終了を待つ必要がある場合があります。この場合、needs属性でjob2がjob1に依存していることを指定することで、ワークフロー全体の正しい実行を保証することができます。
stepsノードでは、現在のジョブが実行する必要のあるステップを定義します。 ステップには2つのタイプがあり、1つはusers属性を使って他の誰かが既に公開しているアクションを直接参照することです。例えば、ここではgithubの公式アクション/checkout@v2を参照し、ホストマシン上でgit checkoutコマンドを実行してコードを取り出します；もうひとつは、run 属性を使用して手動でスクリプトを書く方法です。
必要な機能を実現するためには、実際には4つのステップしかありません：コードを引き出す = node.js環境をインストールする = 依存関係を復元する = リリースをデプロイする。
コードのプルやnode.js環境のインストールは、ビルドのたびにnpm installコマンドを実行してプロジェクトに必要な様々な依存関係をリストアする必要があるので、ここではインストールコマンドを実行する際に、公式のactions/cache@v2を使ってプロジェクトのをキャッシュしてビルド処理を高速化します。
ここでは、依存関係をリストアするために、npm installの代わりにnpm ciを使用しています。 コマンド名からわかるように、ciは主に様々な自動環境ビルドで使用され、package-lock.jsonファイルに含まれる特定の依存関係のバージョン情報を読み取ることで、リストアプロセスを高速化します。
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
# Install node js
- name: Setup Node.js environment
uses: actions/setup-node@v1
with:
node-version: 12.x
# Cache node modules
- name: Cache node modules
uses: actions/cache@v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
# Install required dependencies to build app
- name: Install dependencies
run: npm ci
リストアが完了したら、package.jsonファイル内のdeployコマンドを実行します。 アクションで実行されるコマンドは読み取り専用であることが多いため、deploy操作を実行するのに十分なパーミッションを持つためには、実行時に環境変数にGITHUB_TOKEN変数を追加する必要があることに注意してください。
steps:
# Use angular-cli-ghpages to deploy app
- name: Deploy to github pages
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: npm run deploy
secrets.GITHUB_TOKENはgithubでデフォルトで作成されているので、ワークフローで直接使うことができますが、他の認証が必要なサービスなどでは、yamlファイルに直接パスワードを書き込むのは危険なので、リポジトリの設定タブでsecretsのキー情報を設定してからそして、リポジトリの設定タブでsecretsキー情報を設定することで、ワークフローで直接使用することができ、変数
環境変数を追加したら、実際に実行するnpmスクリプトを調整する必要があります。
ローカルでデプロイコマンドを実行する場合は、ローカルの git 設定に関連するアカウント情報がすでに含まれています。しかしワークフローで実行する場合は、angular-cli-ghpages は匿名状態なので誰がコマンドを実行しているのかを知る手段がありません。そこで、git アカウント関連の設定パラメータを ng deploy コマンドに追加する必要があります。
{
"name": "ingos-admin",
"version": "1.0.0",
"scripts": {
"deploy": "ng deploy --no-silent --base-href=/ingos-admin/ --name='アカウント名='パスワード'',
}
}
この時点で、完全なワークフロースクリプトは以下のようになり、ローカルコードがgithubリポジトリにプッシュされると、自動的にアプリケーションのリリースとデプロイが完了します。
# This is a basic workflow to deploy angular app into github pages
name: Deploy Github Pages
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
push:
branches: [master]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
# Install node js
- name: Setup Node.js environment
uses: actions/setup-node@v1
with:
node-version: 12.x
# Cache node modules
- name: Cache node modules
uses: actions/cache@v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
# Install required dependencies to build app
- name: Install dependencies
run: npm ci
# Use angular-cli-ghpages to deploy app
- name: Deploy to github pages
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: npm run deploy
このコードにはワークフローファイルが含まれているため、githubにプッシュする際に以下のエラーが発生する可能性があり、アクセストークンをリセットする必要があることに注意してください。
GitHub Personal Access Tokens ページを開き、右側にある Generate new token ボタンをクリックして新しいトークンを作成することを選択し、パーミッションの編集時にワークフローがチェックされていることを確認します。
トークン情報をコピーし、コンピュータの資格情報マネージャを開き、Windowsの資格情報タブで、github関連の資格情報を見つけ、既存の資格情報のパスワードをコピーしたトークン情報に更新するか、既存のgithubの資格情報を直接削除します。再ログイン時に、パスワードをコピーしたトークン情報として入力します。
プッシュが成功したら、再度コードリポジトリのアクションメニューをクリックすると、実行されたワークフローレコードが表示され、特定のワークフローレコードをクリックすると、ワークフローの各ステップの実行詳細が表示され、実行状況に応じて自分で調整することができ、自動デプロイの機能が完成します。
- GitHub アクションを使い始めよう
- githubアクションの魔法を体験する時が来ました！
- npm-ci
- Git Extensionsは素晴らしいツールですが、クレデンシャル管理が非常に弱いです。
