Bitbucket PipelinesでCI/CD入門！ビルドとレンタルサーバーへのFTPデプロイを自動化する

こんにちは、デザイナーの岩淵です。
技術系記事のためちょっと長くなります。

LYZONではGitホスティングサービスの中でもBitbucketを利用するシーンが多いです。
デザイナーの業務としてはHTML/CSS/JS周りを作成し表示確認用サイト（レンタルサーバー）へアップロードすることがあるのですが、Bitbucketでソースコード管理している場合はBitbucket Pipelinesを利用すれば面倒な設定を極力行わず簡単にCI/CD（継続的インテグレーション/継続的デリバリー）を導入し、一部の作業を自動化することができます。

この記事ではBitbucket Pipelinesを利用して、Bitbucketリポジトリの特定のブランチへプッシュした際にビルド＆レンタルサーバーへFTPデプロイするという処理を作っていきたいと思います。

Atlassian社が提供するCI/CDツールです。
Bitbucketと連動したサービスなので、Bitbucketユーザーは他サービスをCI/CDとして利用する場合の連携手順が不要ですぐに利用することが可能です。

ドキュメントも公式サイトに充実しているので扱いやすいと思います。

プランによって色々とオプションが違うようですが、クラウド型の場合基本的にはビルド時間に対して課金される従量課金タイプです。

Bitbucket無料ユーザーなら月50分まで無料で利用でき、スタンダードなら月2500分、プレミアムなら月3500分まで課金なしで使えます。
月のビルド時間が超過するとそれ以降はビルド時間1000分で10ドルかかるようです。
※2020年12月時点の情報です。

公式サイトでこのような目安があります。50分はテストしているうちに軽く越してしまうので、複数人で扱う場合は無料プランだと追加料金が発生する可能性が高いですね。

この記事では主にデザイナー・コーダー・フロントエンドエンジニア向けとして、yarnコマンドでビルドしたファイルをレンタルサーバーへFTPデプロイするまでの動作を自動化することを目指していきます。

シンプルに以下のようなイメージです。

1. developブランチへプッシュ
2. 【Pipelines】yarn installやらyarn devなどのコマンドでビルド
3. 【Pipelines】ビルド後の指定ファイルをレンタルサーバーへFTPデプロイ

ビルドやデプロイを自動化することで得られる恩恵は大きいですね。
ビルド後のファイルをGit管理しなくてもいいのでコンフリクトの可能性を減らせたり、違うブランチをサーバーへ反映してしまうなど人為的ミスも減ります。

※以下手順は2020年12月時点の方法です。操作画面など変更されている可能性があります。

まずはBitbucket Pipelinesを導入したいリポジトリの管理画面へ移動し、サイドバーからRepository settingsを選択します。

少しスクロールするとPIPELINESの項目たちが見えてきます。
ここのSettingsに入ります。

するとEnable Pipelinesのチェックがあるので押して有効にします。
このチェックだけで「このリポジトリでPipelinesを利用する」という設定が終了しました。

チェックを入れるとすぐ下のConfigure bitbucket-pipelines.ymlがアクティブになるので、これを押して次の画面に移ります。（このボタンはただのページ遷移なので押さなくても設定は終わっています）

翻訳「やったー！これでパイプラインが正常に設定されました。パイプラインが起動すると、ここに詳細が表示されます。」
という画面に移りました。これであとはymlさえあればPipelinesが動いてくれるようになります。

リポジトリ管理画面左側のサイドバーからDeploymentsを選択します。

スクロールするとこのようなエリアが見えてきます。ここでbitbucket-pipelines.ymlを作成することができます。
このファイルがリモートに存在していることで、プッシュされた際にymlに記載されている設定をもとにスクリプトを動かすことが可能です。
この画面から作成しなくてもテキストエディタなどでbitbucket-pipelines.ymlを作成しプッシュするという方法でも大丈夫です。

右側のChange the templateの中には、よく使われる環境のテンプレートを選ぶことができます。
今回はNode.jsでのビルドを行うので、テンプレートの中からBuild and test a NodeJS codeを選択してください。

他のテンプレートに比べて内容が少ないので分かりやすいと思います。赤文字はコメントで、その下からが処理内容です。
ざっくり説明すると以下のような処理になっています。

細かいymlの書き方は下記リンク先を参考にしてください。日本語ドキュメントで分かりやすいです。

ビルド＆デプロイするために、このようなymlを作成しました。

    image: node:10.22.0
    
    pipelines:
      branches:
        develop:
         - step:
            name: install & dev
            caches:
              - node-modules
              - common-images
              - yarn
            script:
              - cd Design
              - yarn install
              - yarn dev
            artifacts:
              - Design/source/**
              - Design/common/**
         - step:
            name: deploy
            deployment: Test
            script:
              - cd Design
              - pipe: atlassian/ftp-deploy:0.3.3
                variables:
                  USER: $FTP_USER
                  PASSWORD: $FTP_PASSWORD
                  SERVER: $FTP_SERVER
                  REMOTE_PATH: $FTP_DIRECTORY
                  LOCAL_PATH: '${BITBUCKET_CLONE_DIR}/Design/'
                  DEBUG: 'true'
                  EXTRA_ARGS: '--delete --exclude=work --exclude=node_modules --exclude=lib --exclude=.eslintrc.json --exclude=babel.config.js --exclude=gulpfile.js --exclude=modernizr-config.json --exclude=package.json --exclude=README.md --exclude=yarn.lock --exclude=webpack.config.base.js --exclude=webpack.config.development.js --exclude=webpack.config.production.js --exclude=webpack.config.staging.js --exclude-glob=*.bat --exclude=.htaccess --exclude=.htpasswd'
    
    definitions:
      caches:
        node-modules: Design/node_modules
        common-images: Design/common/images
        yarn: /usr/local/share/.cache/yarn
    

以下の内容になります。

    Repository
    ├ .gitignore
    ├ bitbucket-pipelines.yml
    └ Design
    　 ├ node_modules
    　 ├ package.json
    　 ├ common ←デプロイ対象
    　 │ ├ fonts
    　 │ ├ images
    　 │ ├ js
    　 │ └ css
    　 ├ source ←デプロイ対象
    　 │ └ html
    　 ├ work ←ビルド対象
    　 │ ├ pug
    　 │ ├ sass
    　 │ ├ js
    　 │ ├ icons
    　 │ └ images
    　 └ その他コンフィグファイルなど
    

上記で作成したymlをコピーして入力エリアへ入れます。
↓

変数を定義したいので、右側からAdd variablesを選択してください。

リポジトリ全体で使いたいので「Repository」の部分に入力していきます。
見えてたらマズイ部分はSecuredをチェックして●●●●になるようにしましょう。
「FTP_DIRECTORY」はftp-deployのREMOTE_PATHで読み込んでいるとこですね。ここはFTP接続してどの階層にアップロードするのかを決めています。間違えちゃうとヒドイ場所にアップしてしまう可能性があるので注意深く確認しましょう。

ymlの構文やBitbucket Pipelinesの必要設定に問題がなければ、入力画面下がこのようにチェック状態になります。
Commit fileを押すとbitbucket-pipelines.ymlファイルがmasterブランチへコミットされます。
（この時点では他のブランチへコミットされていないことに注意してください。使いたいブランチへはこのコミットをマージする必要があります。）

masterへコミットされたymlをdevelopブランチにも反映します。

するとサイドバーのPipelinesから・・・

リロードしなくてもdevelopブランチへのプッシュを検知して動き出しました。In progressとなっていますね。

ユーザーアイコン右のInitial Bitbucket Deployments configurationの部分にあたるテキストがリンクになっているので押してみましょう。

この画面から今現在どのように動作しているのか詳細を追うことができます。
この画像ではちょうどステップ「install & dev」のyarn installが動いているところですね。

初回はキャッシュがないので時間がかかります。

問題起きなければこのように緑になります。問題があれば赤になります。

無事デプロイされているかを確認してみましょう。
サーバーに指定のファイルが上がっていれば成功です！

サイドバーのDeploymentを選択すると、環境別にどのような状況か確認できます。
複数の環境へデプロイしている場合はここを確認すればエラーが出ていないか一目で分かります。

Pipelinesに戻ってもSuccessfulというように状態が確認できます。
右端にDurationとあります。これがビルド時間であり、料金に関わってくる部分です。
月に利用できる時間の枠からこの数値が引かれていきます。
右上のUsageから簡単な利用状況を確認できます。

キャッシュが正しく機能していれば、右上のCachesから保存されていることが確認できるはずです。ここからキャッシュを削除することもできるので、タスクに問題が起きた際に消してみることも考えられますね。

他にもSchedulesからはPipelinesを動かす日時を予約できたり、Run Pipelineからプッシュせずとも再度動かせたりします。

Deploymentや変数は「Repository settings」の「PIPELINES」からいつでも変えられます。

変数についてのポイントですが、デプロイメント変数 > リポジトリ変数 > ワークスペース変数という強さ順になっています。同じ名前の変数がある場合デプロイメント変数が上書きするというイメージです。
この記事ではリポジトリ変数のみ使用しましたが、ワークスペース全体で使いたい変数は設定の「Workspace variables」から設定することができます。
デプロイ環境ごとに設定したい場合は、リポジトリの「Repository settings > Deployments」から設定可能です。ここで環境の名称を変更したり新たに追加することもできます。

長めの記事になりましたが、Bitbucketユーザーなら他のCI/CDサービスと連携するよりは手順など簡単ではないでしょうか！
今回はftp-deployを使用しましたが、他にもrsync-deployやgit-ftpというものもあり、挙動は違いますがこれらでもFTPサーバーへ反映できるようです。

ymlは他のCI/CDサービスでも使用するので、作業を自動化していくために使いこなしたいですね。