Posts for: #Ci/Cd

backlog-github-integration-action を運用し始めた

#github  #ci/cd 

2時に寝て6時半に起きた。

backlog と github のインテグレーション action の試験運用

昨日作った backlog-github-integration-action を早速お手伝い先の github リポジトリと backlog に導入した。いま暇な時期というのもあって、誰からもクレームが出なかった。この閑散とした間隙を「乗るしかない、このビッグウェーブに」というノリで導入して運用して既成事実を作る。ses でお手伝いに行って課題管理のツールを作っているというのは頭おかしいと思うけど、周りからクレームが出る前に電光石火で運用にのせてしまう。実際に運用で使うといくつかバグがあって、いま latest の docker イメージを使ってカスタム action が動いている。バグがあったら修正して、./gradlew jib (docker push) で新しい docker イメージを gihtub packages に push して、不具合があった pr のジョブを再実行すれば再現環境でテストもできる。いくつかバグ修正をした。実際の運用のデータを使うとばらばらとバグがみつかる。運用で実際に使われていないツールはダメ、絶対。

backlog-github-integration-action を作った

#java  #github  #ci/cd 

0時に寝て7時に起きた。丸一日開発していた。構想1ヶ月、実装2日といったところか。

backlog と github のインテグレーション action

お手伝い先が backlog を課題管理システムとして使っている。backlog は git 連携 の機能をもっているが、これは nulab 社のクラウド上に git リポジトリを構築したものと連携する機能であって、github と連携する機能ではない。そこで github と backlog と連携するためのカスタム github action を作った。

カスタム github action を java で開発するのは普通にはやらないと思うが、いくつか理由があってお手伝い先が java しかできないというのと、nulab 社が提供している公式クライアント nulab/backlog4j が java しかないから。最初は go で実装しようと思って go のクライアントを試したんだけど、サンプルコードをかいたら一部の処理でエラーになって、そのエラーがよくわからなくてやる気がなくなってしまった。最新の rest api の仕様にそってメンテナンスされていないのかな？と思って、やっぱり公式クライアントしかないなと。他にも次のライブラリを使っている。

これまでは commons-cli を使ってきたけど、サブコマンドの機能を提供していない。もうメンテされてないかも？サブコマンドの機能をもつ argument parser がほしくて picocli を選択した。初めて使っていて、実装してみたらわりと私の好みでよく出来ていると思う。今後は cli ライブラリとして picocli を使っていこうと思う。

github actions の課金金額

#github  #ci/cd 

2時に寝て何度か起きてだらだらしながら10時に起きた。

gihtub-api-tools のリファクタリングとデータ分析

実際に使ってみながらリファクタリングしたり、足りない機能を追加したりした。ツールに拡張した機能が使えるかどうかの検証のため、お仕事のプライベートリポジトリのデータを使って分析をし始めて、気付いたら分析ならびに分析結果の資料まで作ってしまった。軽く半日ぐらいのお仕事をやってしまっていた。過去5ヶ月分の課金時間の合計を算出し、単体テストの実行を github actions に追加することで増える課金時間の見積もりと金額を算出した。月間でいまより3時間30分、全体の課金時間に対して20%弱程度の追加が見込まれる。それによる課金金額を算出すると 210 * $0.008 = $1.68 になる。いままで無料枠を超えないように運用してきたわけだが、こんな200円程度の金額を節約するために github actions 上でテスト実行しないといった判断がくだされていた。開発者は誰も実際の課金金額を知らなかったし、課金金額を算出するとあほらしくなった。あと github actions はめちゃくちゃ安い。

gihtub-api-tools の拡張

#github  #ci/cd  #python 

5時に寝て9時過ぎに起きた。昨日は久しぶりに夜更ししてコードを書いてた。

github actions のいろいろな時間の算出

以前作った github-api-tools を拡張して github actions の実行履歴の分析するための機能を作っている。

ひとまずワークフローの実行履歴からジョブのステップの実行時間を積み上げた時間を算出してみた。いくつか API を調べているうちに課金時間は直接 API から取得できることに気付いた。この3つの時間は全然別の意味をもっていて、それぞれの時間は一致しない。

  • ステップ実行時間: ジョブのそれぞれのステップの実行時間の合計
  • 課金時間: 課金対象として数えられている時間の合計
  • ワークフロー実行時間: アクションのワークフローの実行にかかった時間

github actions は public リポジトリに関しては課金対象ではないんやね。private リポジトリ且つ github-hosted ランナーを使っている場合のみ課金対象となるみたい。

github actions の改善

#github  #ci/cd  #book 

0時に寝て3時に起きて6時に起きた。

失敗したジョブの再実行

せらさんのツィートをみかけて調べたら2日ほど前に失敗したジョブからの再実行の改善が行われたらしい。

たまにだけど、i/o エラーみたいな内容で github actions のワークフロー実行が異常終了することがある。そんなときに途中から再実行できるといいなぁとは思っていた。これはステップ単位ではなく、ジョブ単位の実行みたいだけど、それでも途中から再実行できればワークフローの自由度や効率は上がると思う。github actions がどんどん強力になっていくのが楽しみ。あとやぎさんから教えてもらった GitHub Actions 実践入門 も購入した。ある程度触ったところで雰囲気は掴めてきたので体系的に学んでみる。

平穏な一日

#github  #ci/cd 

0時に寝て5時半に起きた。一仕事を終えて淡々と前の作業の続きのリファクタリングなどをしていた。

デプロイ改善のタスク完了報告

週末にパイプライン処理の検証やロールバック処理の実装を行った。ドキュメントも一通り書いた。チームの開発者にそれらを説明して3スプリント(3週間)に渡った改善が完了したことを報告した。チケットにすると26、そのうち私が担当したのが22なので、私がイニシアティブをとって完遂させた。github actions を始めとする、github のサービスの理解が深まってそれなりに学びがあった。自分でもいくつかカスタム action を作ってみようと思う。

デプロイ改善の残作業

#life  #github  #ci/cd 

23時に寝て2時に起きて4時ぐらいまでだらだらして寝て6時に起きた。

ストレッチ

これまで11時からストレッチを受けていたが、今週から dr.stretch さんの土日の開店時間が10時になったのにあわせる形で時間変更した。朝に予定が入っているとその時間にあわせて起きて身支度して1日が始まるので家で中途半端にだらだらしなくてよい。いつもは11時にあわせて家を出掛けるのが、10時にあわせて出掛けるようになったのでいつもより1時間早く活動できるようになった。私はなんか予定がないとだらだらしてしまって怠惰に過ごしてしまう。そういう怠ける自分の性格もわかっているので適度に予定を入れて怠けないように注意している。

今日の開脚幅は開始前163cmで、ストレッチ後165cmだった。先週とほぼ同じ。今週もお仕事が忙しくて全くできなかったので現状維持といったところ。

デプロイのパイプライン処理

github deployment から workflow dispatch に移行したおかげでせっかく deployments ベースで作ったパイプライン処理のツールを workflow dispatch 向けに移行する必要があった。言うても基本的に同じパラメーターを処理するだけなので大半は再利用できる。ツールのちょっとしたリファクタリングをやってパイプライン処理が動くかどうかの検証をして、ドキュメントを wiki にまとめた。あとはロールバックを自動化するための仕組みを作るだけ。基本的には k8s の kubectl を実行するワークフローを作るだけという想定。

デプロイ改善の成果まとめ

#book  #github  #ci/cd 

23時に寝て5時過ぎに起きた。何度か途中で起きたけど、久しぶりによく寝た。前日あまり寝てなかったから19時過ぎには帰ってきてだらだらしてた。

もてなしだけではもう食えない

業界研究を兼ねて もてなしだけではもう食えない -ホテル経営学の本質と実践- を読み始めた。同じ出版社の週刊ホテルレストランという雑誌の連載を書籍化したものらしい。著者は立教大学で社会人向けビジネススクールでホテルマネジメントとホテルインベストメントを教えているらしい。ビジネスの堅い話しを小説調にすれば読みやすいんじゃないかみたいな取り組みなのかな？よくわかてないけど、小説仕立てで業界研究ができるような書籍になっているらしい。第1章プロローグと第2章腐りやすい在庫を読んだ。実際の現場でこんな仕事できない人が改革チームのリーダーなんかになったりしないなと思いながら読んでた。そこは本題じゃない！コンサルティングでありそうな経営の話しが出てくるのでうちの会社の経営の勉強にもなるかもしれない。少しずつ読んでいく。

デプロイ改善の成果

水曜日がすくらむのふりかえりイベントがあるのでそれに間に合わせて簡単にまとめの資料を作った。3スプリント (3週間) もかけて抜本的に開発のワークフローからビルド/デプロイの ci/cd を見直したので開発全般に影響を与えた。

  • 本番環境デプロイ: 実行時間を約72%の短縮
  • テスト環境デプロイ: 実行時間を約51%の短縮
  • hotfix デプロイ: 実行時間を約64%の短縮
    • そもそも従来のやり方では hotfix を出していないので机上の時間ではあるが

単純に github actions の実行時間だけ比較しても速くなっているのだけど、それ以上にブランチ戦略を大きく変えた。従来は3つのブランチで運用していた。

  • develop
  • test
  • main

これを1つのブランチのみで運用できるように開発のワークフローを刷新した。ブランチが1つしかないので ci/cd の戦略もシンプルになって、変則的な運用 (hotfix を出したいとか) をしても、開発全体に影響を与えない。「誰か勝手にブランチを作ってデプロイして」で終わる。従来のやり方は3つのブランチが開発ワークフローと ci/cd に密接であったために本番環境のリリースするときは開発すべてが止まってしまう状態だった。週1回のリリースだったので本番リリース前の1-2日は PR のレビューやマージを止めているという運用になっていた。それは開発速度に大きな影響を与えていた。ブランチ戦略を見直したことでいつでも本番環境にデプロイできるようになって、継続的デリバリーっぽいことがやりたかったらできるよという話しをした。

ワークフローの移行説明

#github  #ci/cd 

3時に寝て6時半に起きた。朝起きたら github actions のリソース上限に達しているという連絡が slack に書き込まれていて週末に移行作業して1500分ぐらいは浪費しましたと事後報告した。

ワークフロー移行後の説明

週末に移行した新しい ci/cd の仕組みを開発者に説明した。開発のワークフローも大きく変わる。いくつか要望をもらいつつ、とくに混乱も誤解もなく受け入れられた。github actions の管理画面からボタンでデプロイ実行できるため、本番環境にデプロイできるユーザーは制限したいと言われて次のようなステップを追加した。

- name: デプロイユーザーを確認
  if: ${{ env.DEPLOYMENT_ENV == 'prod' }}
  run: |
    [[ "${{ contains(fromJSON(env.DEPLOYABLE_USERS), github.actor) }}" == "true" ]] && exit 0
    echo "デプロイ権限のあるユーザーではありません"
    exit 1    
  env:
    DEPLOYABLE_USERS: '["user1", "user2", "app-bot"]'

expressions の Functions に組み込みの関数がいくつか紹介されている。それらを組み合わせるとうまくいきそうと思って書いてみた。たしかにちょっと楽に実装はできるけど、github actions の expression とシェルの文字列との境界が、yaml のコード上では曖昧なため、真偽値などはとくにわかりにくい。例えば、次のコード。

[[ "${{ contains(fromJSON(env.DEPLOYABLE_USERS), github.actor) }}" == "true" ]]

${{ ... }} で囲まれたところは github の expression なので boolean として評価できるが、それをシェルにもってくると文字列になってしまうので文字列で比較しないといけない。普通にコードを書いていて気づきにくいので実行して振る舞いを検証しないと間違うみたいな話し。

もっとさいきょうのでぷろい

#github  #ci/cd 

ぼくのかんがえたもっとさいきょうのでぷろい

昨日 ぼくのかんがえたさいきょうのでぷろい を実装したんだけど、その後、残っていた残課題に対応しているうちにもっと最強のデプロイ方法があることに気付いた。結論から言って GitHub Deployments を使う必要がなかった。GitHub Deployments で過去のリビジョンを指定したときは次のような 409 エラーが発生する。

gh: Conflict merging main into f0cff65c94c4a242efebc79c8fb1e31d58d2f592. (HTTP 409)

これを回避するためにどんな手段があるかなと workflow dispatch event をみていて inputs というパラメーターがあることに気付いた。あれ？workflow dispatch ってパラメーターを受け取ることができたんだっけ？と調べたら2020年7月ぐらいからできるようになってた。

github actions の web ui とも連動していて画面からもパラメーターを渡せるようになっていた。jenkins で言うところのパラメーター付きビルドと呼ばれる機能。カスタムアクションの inputs と同じような使い勝手で利用できる。workflow dispatch がパラメーターを受け取れるなら GitHub Deployments を使うメリットって何があるっけ？と思ったら何もなかった。GitHub Deployments を使うことで無駄にリソースを浪費してパイプライン処理を複雑化させるデメリットしかなかった。inputs に渡す型に environment を指定すると、環境の制限や権限、protected branch などにも応用できるらしい。但し、この environment は public リポジトリか、github enterprise でしか高度な設定はできないみたい。GitHub Deployments 経由でリソースの作成自体はできる。

週末は休出

#life  #github  #ci/cd 

2時に寝て8時頃に起きた。前日に深夜まで開発してたせいか、朝起きたら頭痛かった。

ストレッチ

お仕事に集中していて今週は1回しかストレッチができなかった。今日の開脚幅は開始前164cmで、ストレッチ後165cmだった。先週と同じぐらいかな。それでも毎週予定が入っているので必ず週に1回はちゃんとしたストレッチを受けられる。もう1年以上続けているのだけど、以前より体調のよい状態をずっと継続できている。私はなにかに集中すると他のことをしばらく放置してそればっかりやってしまう傾向があるから毎週の予約があることが継続的な体調管理に大きく役立っている。太ももの後ろの筋肉と腰のストレッチの2つを楽しみにしている。デスクワークをする人は基本的にこの2つに疲労が蓄積するので疲労が溜まるのは自然と言える。その度合いがどのぐらいかでその週の疲労感や調子がよくわかる。今日は先週よりもその2つはましになっていた。

ぼくのかんがえたさいきょうのでぷろい

ここ2週間ほど、ビルドとデプロイの分離のための作業をしている。具体的には GitHub Deployments と GitHub Actions を組み合わせて、新たな開発のワークフローを作るといったもの。main, test, develop と3つのブランチで開発/運用しているのを main ブランチ1つに統合し、ビルドもデプロイも最小限に留めて継続的デリバリーを目指すというもの。移行時は開発を止めてしまうのでこの土日で作業する予定だった。準備は十分にやっていたので問題なく移行を完了させた。今日は単体リポジトリのテスト環境へのデプロイができるところまでできた。あとはデプロイツールや github actions の処理を洗練させていくだけ。テンションが上がっているのでこのまま明日も休出してできるだけ品質をあげていく。