GitHub Actions を回してピザを頼みたい - いなにわうどん
年の瀬ですね。クリスマスの足音も近く、ピザなんかを頼んだら景気が良いかなと思ったので、GitHub 上で Issues を生やすとピザが頼める仕組み（workflows）を構築してみました。 本記事は mast Advent Calendar 2023 の 7 日目の記事です。6 日目は Hitoko T. 先生の記事「我が家に猫3匹がやって来た話｜Hiroko T.」でした。猫、癒やしですよね 折角のアドカレの機会ですから、GitHub 上でピザを頼むまでの過程を、GitHub や Web 技術、ピザ等に明るい方にも、そうでない方にもお楽しみいただけるように説明*1*2を進めていきます*3。少し長くなりますが、どうぞお付き合いください。 ピザ 突然ですが、みなさまはピザと呼ばれる食べ物をご存知でしょうか？ 初めてピザをご覧になられた方に向けて説明しておくと、小麦粉等を練って構成した生地を
Flutterアプリの定期リリースを支える自動化 - Fast DOCTOR Technologies TECH BLOG
本稿では、ファストドクターのモバイルアプリのリリースフローを整備した取り組みについてご紹介します。 モチベーション ファストドクターのモバイルアプリは、2022年夏にFlutterでのフルリプレースを実施し、それ以降は機能の開発が完了次第随時リリースをするという戦略を取っていました。 この戦略はシンプルであり、開発に関わっているステークホルダーが少ない状況下でうまく機能していました。しかし、組織の拡大に伴い以下のような問題が発生するようになりました。 複数機能の開発スケジュールの調整をしたり、バックエンドのリリース・QAとの整合性を取ったりという必要性が増し、調整コストが肥大化 リリースが不定期なため、いつPull Requestをマージすれば良いか分からずopenされたままのPull Requestが多数 この状況を改善するために、以下の要件を念頭に定期的なリリースとそれを支える仕組みを
GitHub Actions で AWS を操作する（Lambda編） - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
こんにちは。開発部門（プロダクト技術本部）の宮下です。 BIGLOBE では GitHub Actions による作業効率化に取り組んでいます。 本記事では、GitHub Actions が得意とする点を踏まえつつ、AWS Lambda と連携して手作業を大幅に減らす実例をソースコード付きで紹介します。 想定読者 GitHub Actions を使うと何がうれしいのか？ 代表的なユースケース あまり向かないユースケース 事例紹介 課題 改善後 API コンテナ リグレッションテスト用 Lambda パフォーマンステスト用 Lambda 自動化による効果 Lambda を実行するアクション GitHub Actions で使えるアクション ソースコード ポイント、はまったところ GitHub Actions の制御 / ステップ間での値の受け渡し GitHub Actions の制御 / 複
CI/CD方針、テスト・QA方針と連動する三分類ブランチ管理方針で、開発での高品質と高スピードの両立を支える - 千里霧中
最近の開発では、CI/CD、自動テスト、継続的テストが当たり前となっていますが、その影響で、それらのCI/CD方針、テスト方針と、Git等のバージョン管理のブランチ方針をどう連携させるかが、定番の課題になっていると感じています。 今回は、このブランチ方針、CI/CD方針、テスト方針を連携させて、開発の品質とスピードを向上させるアプローチについて解説します。 結論から言うと、要点は以下の二つとなります。 バージョン管理のブランチ方針は、CI/CD方針、テスト・QA方針と不可分であり、連携を考えながら方針立てする必要がある ブランチ方針の工夫で、CI/CD、テスト・QAの開発インフラリソース消費を削減でき、本当に重要なポイントに開発インフラリソースを投入できる。これにより、限られたリソースでの高品質・高スピードの両立を支えられる 背景：開発インフラの進化が全てを解決すると楽観視していた発展期
FlutterのCI/CD環境のAWS EC2(Mac)環境に構築してパイプライン実行速度を改善する - Qiita
背景 現在Flutterを用いたモバイルアプリの開発を行なっているが、その中でGitlabによるCI/CDを構築している。 こちらを運用していくにあたって1点問題が発生した。 それは、メンバーの増加によって相対的にCI/CDのビルド端末が不足し、pipelineの滞留が発生したことだ。 pipeline待ちがDeveloperのストレスになったり、作業効率の低下を招いたりすることは既に広く知られてはいるため本件を早急に解決する必要がある。 基本的には、CI/CDのRunnerとなるMacを購入して、処理台数を増やすことで、本件を解決することができる。 しかし、この問題の解決には以下のような課題がある。 Mac端末の購入にはリードタイムが必要であり、解決まで時間がかかる。 新規で購入した端末では新たに環境構築が必要であり、人的リソースがかかる。 メンバーの増加は一時的なものであり、減少した際
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
