CircleCIからデプロイする云々
今年からCircleCIを利用中。
基本無料になったこともあって、Jenkinsさんを自前で立てるよりCircleCIで、というのがデフォルトになっている。
CIをパスした後のアクションとしてデプロイの設定も出来るので、いくつかのプロジェクトで試した知見をメモしておく。（なおCI後のデプロイはJenkinsさんでも可能）
具体的な設定方法はネットをあさればたくさん例が出てくるので割愛。
メリット
- GitHubにpushするだけでデプロイができる
- CIをパスしたものだけがデプロイされる
GitHubのデプロイ用ブランチにpushすればデプロイできるようになるので、Gitの操作さえ分かれば誰でも簡単にデプロイできるようになる。
ローカルにデプロイ環境を整える必要も、特別なコマンドを覚える必要もない。
これは何と言ってもデザイナーさんが気軽にデプロイできる、というのがすこぶる便利で、文言修正やデザインの微調整などの反映がスムーズになる。ぶっちゃけるとデプロイ依頼がこっちに飛んでこないので楽ｗ
ただすべてのデザイナーがGitを使いこなせるわけではないので、期待通りにいかない残念なケースもある。
それからデプロイ前に必ずCIが走ると言うのも分かりやすいメリットのひとつ。
デメリット
- CircleCIに障害が起こるとデプロイできない
- CircleCIの仕様変更でCIが通らなくなることがある
タイミング的に影響はうけていないが、今年はCircleCIが何度かダウンしている。
CircleCI側の対応は迅速かつ真摯なものだったが、障害中はデプロイができなくなるため、そうした場合の対応は決めておいた方がよいだろう。
緊急性がなければCircleCIの復旧を待つということで行きたいが、念のためにローカルから手動でデプロイする手順も把握しておいた方がベター。
あとはCircleCIのapt周りの挙動が変わってdependenciesの部分で必要なライブラリが入らなくなってしまったため、設定を変更したことが一度あった。OSにデフォルトで入っているパッケージが変わったんだったっけな。
このように何らかの原因でCIが動かなくなったときの問題解決のため、CircleCIの設定ができる人材を確保しておく必要がある。
具体的には開発後の運用フェーズの体制的にそこがネックでCircleCIの継続利用を諦めたケースがあった。まあさほど規模も大きくないWordPress案件だったので、あとは手動アップロードでもなんとかなりますよね、的な背景もあり。
とは言え、開発中には十分に役に立ったかんじ。
一年以上ぶりの2015年滑り込み更新。ずさー。
間があくと腰が重くなるので、軽いトピックでもちょくちょく更新していこうかなと。備忘録大事ですし。乱文乱筆気にしない。
