本セッションでは、弊社開発のスマートフォンゲーム『IDOLY PRIDE』のUnity開発フローにおける効率化テクニックについてご紹介します。 「IDOLY PRIDE」は今年でリリースから3周年を迎えようとしており、様々なイベントや機能を頻度高くリリースしてきました。Unity開発においては、社内の開発基盤やブランチの自動運用など様々な効率化テクニックにより運用が支えられています。 今回はそのテクニックについて具体的に解説します。 https://cagc.cyberagent.co.jp/2024/session/index.html?id=bU5Ar3jh Copyright © CyberAgent, Inc.
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
はじめに 前提情報 プロダクトチームの体制 Four Keys の Elite を目指して 品質保証の課題 1. テストの重複 2. 刻々と変化するチーム体制 3. 属人化したテストケース管理 改善策:テストプロセスの変更とテストケース管理ツールの導入 1. テストプロセスの改善〜Test It Yourself〜 2. テストマネジメントツールの導入 おわりに はじめに こんにちは、テックタッチで QA PM (Quality Assurance Project Manager)をしている shutty です。先日はテストエンジニア向けの合宿型ワークショップ WACATE2023 冬に初めて参加してきました。実行委員をはじめとして参加者全員の熱量を全身に浴びてきました。 この記事では最近テックタッチの開発チームで行なっているテストプロセスの改善について紹介します。 前提情報 プロダクトチ
こんにちは。SRE部の巣立(@ksudate)です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー
Docker創始者らが開発、ビルド/テスト/デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に Dockerの創始者であるSolomon Hykes氏らが中心となって開発しているオープンソースのCI/CD環境構築ツール「Dagger」が公開されました。 Windows、Mac、Linuxで試すことができます。 And we are live! Introducing Dagger, a new way to build CI/CD pipelines. By the creators of Docker. https://t.co/DU8racmoUo — dagger (@dagger_io) March 30, 2022 Daggerが定義したCI/CDパイプラインはポータブルになる Daggerとは「A P
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
こんにちは、技術広報のyayawowoです。 「自動化(オートメーション/Automation)」 今、この言葉を聞いて胸がときめいた方に必見です! 当社主催イベントでも人気の高い 「自動化大好きエンジニアLT会」全5開催分の資料をまとめて紹介します! イベント詳細はこちらをご確認ください! ・自動化大好きエンジニアLT会 ・自動化大好きエンジニアLT会 - vol.2 ・自動化大好きエンジニアLT会 - vol.3 ・自動化大好きエンジニアLT会 - vol.4 ・自動化大好きエンジニアLT会 - vol.5 目次 目次 手動テストやインフラ構築は自動化しよう APIテスト品質を向上させる Datadog Synthetic Monitoring APIテスト自動化とテストピラミッド TestLinkにテスト結果を自動的に登録 Cypressでサクッと始めるE2Eテスト 自動テスト環境を
【注意】この記事で紹介しているSMS APIサービスのVonageは利用規約により認証にVonageの電話番号を利用することを禁止しているという記述があるので、末尾の別解として載せたAndroidデバイスを使ってSMSを転送する方法が良さそうです。 help.nexmo.com 2021年2月から、App Store Connectにログインする際にすべてのApple IDで2ファクタ認証が必須になります。 Starting February 2021, additional authentication will be required for all users to sign in to App Store Connect. This extra layer of security for your Apple ID helps ensure that you’re the only
この記事は 「Develop fun!」を体現する Works Human Intelligence Advent Calendar 2020 21日目の記事です。 昨日の記事は@sparklingbabyさんのStream API がもっとわかる記事でした。 あらすじ 私は2019年にWorks Human Intelligence(正確には分社前の会社)に新卒入社し、 19年10月からプロダクト開発部門に配属され、SETエンジニアとしてとある製品のJava開発環境の改善に取り組んでいます。 ざっくりとプロダクト開発を紹介するとこんな感じです。 3万クラス程度ある大規模Java Webアプリケーション 開発環境はEclipseを使用 開発者のOSはWindowsのみ Before 私が開発チームに参加した時点では 部門として新規開発に注力しており、足下の環境改善をやる担当者がおらず、 い
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
DroidKaigi 2019登壇資料 2019/02/08 10:30-11:00 Room 2 スライド内で紹介したリンク - git-flow cheatsheet Git-Flowの解説をしている代表的なサイト https://danielkummer.github.io/git-flow-cheatsheet - bitrise.yml スライド内で紹介したBitrise用の汎用yamlファイル https://gist.github.com/KazaKago/7d91f3740345889e9812e6aecd9d98a4 - StepReleaseDispatcher スライド内で紹介したPlayストアにおける自動的な「段階的な公開」を行うためのKtor製サーバープログラム https://github.com/KazaKago/StepReleaseDispatcher
こんにちは。技術部モバイル基盤グループの @giginet です。 fastlaneのCore Contributorを務めており、 社内ではプロのコードサイン解決者 *1 としての職務経験を積んでいます。 今回はクックパッドでのfastlaneを使ったiOSアプリのサブミット自動化と、証明書管理についての事例を紹介したいと思います。 CIによるiOSアプリサブミットの自動化 クックパッドでは、昨年の春頃よりiOSアプリのサブミットをチャットbot経由で行っています。 このように、Slack上でサブミットジョブを実行すると、CIでアプリがビルドされ、審査提出までを完全自動で行ってくれます。 審査提出には、ビルドや処理待ちの時間を含めると多くの工数がかかり、人為的なミスが起こる可能性もありましたが、 完全な自動化により、高頻度のアプリリリースに耐えられるようになりました。 アーキテクチャは以
アプリケーションエンジニアの西辻です。 今回の記事では、弊社内で開発している Android アプリを master ブランチマージで Play Store Beta に公開するまでの方法についてご紹介したいと思います。 また、今回の記事は Qiita Android その2 Advent Calendar 2017 5日目に参加しています。 Overview 大きく以下の項目について書いていこうと思います。 はじめに Play Store 公開までの全体の流れ CI 環境の設定方法 Play Store Beta に配信するまでの時間について apk ファイルを Play Store に公開するライブラリの設定方法 Play Store での公開方法について 半年運用して分かったこと 間違えて apk ファイルを Play Store Beta にあげた時の対応 Proguard を有効
最近、CircleCIを使っている人が増えてきている感じがします。 CircleCIはgithubのプライベートリポジトリも使えて非常に便利ですし、私も1ユーザです。 そんな私が、最近悩んでいたこと&対応したことについて以下につらつらと書いてみました。 やりたいこと iOSアプリの開発でgithubのプライベートリポジトリを使っているが、1リポジトリ内に複数アプリのプロジェクトがある。 各プロジェクト単位でビルド・テストなどをやりたい。 課題 CircleCIは1リポジトリで1プロジェクトしか作れない。 ※1アプリで1リポジトリを使えるなら良いのですが、プライベートリポジトリをさくっと増やすのはきついのです。 解決策 アプリ単位でブランチを用意する。 CircleCIはブランチ単位でビルドやテストを走らせることが出来るので、各アプリ単位でブランチを用意しておけば良いと気付きました。 対応方
はじめに 皆様、新年あけましておめでとうございます 今年も不定期に思いつきで記事をあげていくのでよろしくお願いいたしますm(_ _)m 昨今TravisCIに代表されるCIサービスが流行ってますね。 Rettyでは内製JenkinsでCIを頑張っているのですが、CircleCIでiOSのBetaできるよって公式ドキュメントを見つけたので、大晦日〜正月にかけてトライしてみました。 だいぶ記事が長いので「結論から知りたい」という方はこちらのまとめから御覧くださいませ。 CircleCI事始め アカウントの作成 まずはアカウントを作ります。 アカウントはGithub認証を利用したものになるため、Githubアカウントがないと登録できません。 CircleCIのアカウント作成はこちらからどうぞ。 対象リポジトリの選択 登録したらまずはCI対象にするリポジトリを選びます。 アカウントにOrganiz
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか?もしくはコードカバレッジだけにとらわれすぎていないでしょうか? 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
この記事において利用している.travis.ymlとRakefileの全体はGistにて公開しています。 ↓ Rakefileの全体はこちら gist.github.com/kishikawakatsumi/8918124 ↓ .travis.ymlはこちら gist.github.com/kishikawakatsumi/8918365 概要 ユビレジではiOS アプリを申請する際に発生する作業の大部分をCIで自動化しています。 申請の作業としてユビレジでは下記のワークフローを決めています。 1. リリースブランチを作る 2. リリースするバージョンのバイナリをビルドする 3. 2と同等のアプリケーションを社内に配布して最終チェックをする 4. クラッシュレポートのサービスとしてCrittercismを利用しているので、そこにデバッグシンボル(dSYM)をアップロードする 5. 2のバイ
現代の開発現場において欠かせないCI/継続的デリバリを、iOSアプリ開発に適用するためのツールやノウハウを解説する連載。 iOSアプリ開発でもCI/継続的デリバリしようぜ(終): Jenkins+HipChat+Hubotをチーム開発に導入してお手軽CI 現代の開発現場において欠かせないCI/継続的デリバリを、iOSアプリ開発に適用するためのツールやノウハウを解説する連載。最終回は、Jenkinsと連携させやすいチャットツールHipChatやBotフレームワークHubotを組み合わせてCIをより効率的に回す方法について解説します。(2014/8/25) iOSアプリ開発でもCI/継続的デリバリしようぜ(5): アプリのクラッシュリポートを統計解析できるBugSenseの使い方 現代の開発現場において欠かせないCI/継続的デリバリを、iOSアプリ開発に適用するためのツールやノウハウを解説する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く