サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
2024年ランキング
swet.dena.com
こんにちは、SWETの川口 ( @yamoyamoto ) です。SWETではCI/CDチームの一員として、GitHub Actionsセルフホストランナー基盤の開発・運用に取り組んでいます。 今回は、私たちのチームがDocker Hubのレートリミット回避とコスト削減のためにミラーサーバーを導入した事例を共有したいと思います。 目次 はじめに 課題解決に向けた検討 既存ソリューションの検討 Google Cloud - Artifact Registry (mirror.gcr.io) AWS - Amazon ECR Public Distribution を利用したミラーサーバーの構築 Distribution について リクエストの処理フロー 検討が必要だったポイント ストレージの選定とパフォーマンス検証 S3、filesystemの構成 S3の場合 filesystemの場合 ミ
こんにちは、SWETの秦野です。 2024/8/22のCEDEC2024にてIKさんと私でRoslynアナライザーに関する発表を行いました。 そして先日、本発表で紹介した静的解析ツールをOSSとして公開しました。 本記事では、CEDECの発表内容と公開したツールについて紹介していきます。 また、本ツールで実装されている静的解析技術(主にフロー解析)について解説します。 CEDEC2024での発表 発表資料はこちらにあるので、本ブログでは概要だけ紹介します。 本発表では、社内のあるゲーム開発プロジェクトにC#の静的解析ツールを開発・導入した事例を紹介しました。 静的解析ツールはRoslynアナライザーとして実装しました。 本ツールは構文解析だけでなくフロー解析を行っていて、文の実行順序や変数の定義と参照の関係を認識できます(この詳細については後述します)。 弊社では本ツール以外にも複数のRo
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
こんにちは。SWETのAndroidチームに所属している外山(@sumio_tym)です。 2023/03/10にAndroid Test Night #8を開催しました。 約3年ぶりのオフライン開催で、懇親会も実施しました(同時にオンラインでも配信しました)! 本記事では、今回の発表のスライドを紹介していきます*1。 聴衆の反応 Android Test Night #8 で盛り上がっている様子にtweetをまとめました。 発表スライド紹介 @STAR_ZERO「Coroutines Test 入門」 1つめは@STAR_ZEROさんによるKotlin Coroutineが関係するテストの書き方についての発表でした。 suspend関数のテスト、メインスレッドの差し替え方法、Flowのテスト例が簡潔にまとめられており、とても参考になりました。 ついつい忘れてしまいがちなStandardT
SWETグループの長谷川( @nowsprinting )です。 開発者自身の手によるUnityプロジェクトの品質向上アプローチのひとつに、ゲームプレイを自動化するオートパイロットによる検証があります。 このアプローチについて、DeNA内で開発・導入を進めているフレームワークAnjinを昨年紹介しました。 swet.dena.com また、Anjin自体も先日オープンソース化しました。こちらのリポジトリからご利用いただけます。 github.com 本記事では、Anjinの、主にオートパイロットを安定運用するための機能を紹介します。 Automated QAが保存するスクリーンショットの退避 uGUIコンポーネントのシナリオテストを行なう UGUIPlaybackAgent の実装には、 Automated QAパッケージ のRecorded Playback機能を使用しています。 Pla
こんにちは、SWETグループ所属のkariadです。 昨年10月に開催されたiOS Test OnlineにてSWETチームのkuniwakが「実践9つのメモリリークどう見つける?」というタイトルで発表しました。 その発表では触れられなかった、メモリリークから引き起こされるOOMクラッシュを発見する手法についてSWETで実践したことを紹介します。 メモリリークについての説明は多くの記事で説明されているため、省略します。 OOMクラッシュ メモリリークが発生するとOOMクラッシュの危険性があります。 OOMとはOut Of Memoryの略であり、アプリが確保しているヒープ領域を超えてメモリを利用しようとした際に、OSからアプリがキルされクラッシュしてしまいます。 通常のクラッシュにおいては大半のアプリで導入されているであろうFirebase Crashlyticsにて検知可能です。 一方で
SWETグループの長谷川(@nowsprinting)です。 開発者自身の手によるUnityプロジェクトの品質向上にはさまざまなアプローチがあります。 当ブログでもこれまでに、 ユニットテスト や 静的解析 といった、コーディング段階でC#コードの品質(特に内部品質)を高めるアプローチを紹介してきました。 本記事では少し目線を変えて、ゲームがほぼ組み上がった状態でのゲームプレイを自動化する、オートパイロットによる検証アプローチを紹介します。 オートパイロットによる検証の位置付けと目的 ゲームが組み上がった状態とは、ゲームを構成するC#コードや3Dモデルなどのアセットファイルを組み合わせた、結合度の高い状態を指します。 結合度を突き詰めると、IL2CPPビルドしてスタンドアロンプレイヤー(モバイル端末やコンソール機)で実施するテストになりますが、今回は結合度を上げすぎず、実行環境はUnity
こんにちは。SWETのAndroidチームに所属している外山(@sumio_tym)です。 SWET AndroidチームではAndroidのプロダクトに対して自動テストのサポートをしています。 はじめに 先日開催されたDroidKaigi 2022で「Gradle Managed Virtual Devicesで変化するエミュレータ活用術」というタイトルで登壇しました。 本セッションの動画もYouTubeのDroidKaigiチャンネルに公開されていますので、合わせて参考にしてください。 さて、本記事では、上記セッションの内容から開発PC上でGradle Managed Devices (GMD)を試すのに必要な部分だけを抜粋して紹介していきます。 本記事を読むだけで手っ取り早くGMDを試せるように構成してありますので参考にしてみてください。 Gradle Managed Devices
SWETグループのLint大好きマンKuniwakです。2022/11/18にオフライン・オンライン同時開催の勉強会「Lint Night #1」を開催します! Lint Nightはプログラミング言語不問でLintに関するトピックを取り扱う勉強会です。ここでLintとはソースコードや文書を静的に解析して問題をみつけるツールのことです。ただ、どこまでをLintとするかには幅があるようです。 さて、Lintの面白いところはソースコードや文書を入力データとして扱うプログラムであることです。ソースコードを入力データとするプログラムといえばコンパイラやインタプリタがあげられますがいずれも実装がかなり大変です。しかしLintはそこまでではありません!実は手軽に実装できるんです(Lintの作り方については次のスライドをご覧ください)。 しかもそれでいてコードレビューを一部自動化できて実用的ですし、ソー
こんにちは、SWETでCI/CDチームの前田( @mad_p )です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに 先日開催されましたCEDEC 2022にて、Gitリポジトリの肥大化に対応した事例を発表しました。これはそのフォローアップ記事となります。以前に出した記事の続編でもあります。 発表資料は次の場所に置いていますので、参照してみてください。 CEDiL(要登録): https://cedil.cesa.or.jp/cedil_sessions/view/2600 Speaker Deck: https://speakerdeck.com/dena_tech/kaorumaeda_cedec2022 Gitリポジトリの肥大化問題 前提となっている課題をおさらいしておきます。 Gitリポジトリは
SWETグループのKuniwakです。iOSコミュニティの皆様にとってはお久しぶりです! 早速本題ですが、夜開催のiOS Test Onlineを始めます!iOS Test Onlineは、iOS Test NightやiOS Test TeaTimeと同じくiOSアプリのユニットテストやUIテスト、継続的インテグレーション(CI)などiOSアプリのテストにまつわる技術的な発表の場です。 「iOS Test 〜」系勉強会が多すぎる!と思った方向けに説明すると、それぞれのイベントは開催時間帯と開催形態で分かれているだけで発表内容や発表ボリュームは変わりません。 イベント 開催時間帯 開催形態 iOS Test Online 夜 オンライン iOS Test Night 夜 オフライン iOS Test TeaTime 昼 オンライン さて、このiOS Test Onlineについて発表者を募
こんにちは、SWETグループの鈴木穂高(@hoddy3190)です。 SWETグループのメンバー向けにIsabelle/Isar勉強会を開催しました。本記事では、勉強会の概要の紹介と、勉強会の資料の公開をします。 もしよろしければご活用ください。 Isabelleとは Isabelleは、定理証明支援ツールの1つです。 数学の授業で証明を解く時、暗記した定義や定義を引き出して仮定や結論をみて試行錯誤しながら適用して解いていっていたと思います。Isabelleを使うと、利用できる定理を提示してくれたり、自動で定理を適用して証明を進めてくれたり、誤った証明を指摘してくれたりします。 Isabelleの大きな特徴として強力な自動証明が挙げられます。自動証明機能の典型例であるSledgehammerは、証明したい論理式を与えれば自動で定理を適用して証明を解き進めてくれます。 公理系も選択可能です。
こんにちは、SWETの鈴木穂高(@hoddy3190)です。 現在SWETチームにて仕様の欠陥をなるべく早くみつける取り組みにチャレンジしています。 欠陥をみつけるタイミングが早ければ早いほど、開発中の手戻りに伴うコストを抑えられます。 たとえば、仕様作成フェーズ、実装フェーズ、QAフェーズの順で開発が進んでいくときに、仕様の欠陥が実装フェーズやQAフェーズでみつかると実装やQAのやり直しを引き起こしかねません。 そうした大きな手戻りを抑えるために仕様の欠陥をなるべく仕様作成フェーズでみつけることを目指します。 対象領域に出てくる要素をモデリングすることは、仕様に潜む欠陥を開発の早い段階でみつけるための、有効な手段のひとつです。 要素には、開発者がこれから作るシステムや、そのシステムのユーザー、そのシステムと直接的または間接的に相互作用する外部のシステムが含まれます。 単に図を書くというモ
SWETグループの平田(@tarappo)です。 早いもので2021年度もとうとう終わりをむかえようとしています。 ふりかえりということで、ここ1年ほどの間に私も関わって進めていた次の2つの施策についてかんたんに紹介したいと思います。 プロジェクトの健康状態の可視化と予防(dev-vital) 自動テストの適用範囲の拡大 今回紹介するこれらの施策は、SWETメンバーの今までの経験などを元に議論した中で出てきた課題から決めています。 プロジェクトの健康状態の可視化と予防(dev-vital) 私がSWETに所属してある程度の期間がたちますが、いろいろなプロジェクトに関わってきました。 その中で感じたのは、あるプロジェクトで出会った課題は他のプロジェクトでも起きていたりするということです。 今までのSWETの取り組みはプロジェクトですでに起きた課題に対してアプローチをとることが一般的でした。
はじめに SWETグループのGoチームの伊藤(@akito0107)です。 「テスタビリティの高いGoのAPIサーバを開発しよう」というタイトルでGoを用いてWeb APIを書くエンジニア向けのハンズオンを公開しました。 この記事ではハンズオンの内容と補足を紹介しようと思います。 ハンズオンのねらい このハンズオンでは、APIサーバーを題材としてテスタビリティを担保した設計をするためには何が必要なのかを学んでもらうことを目的にしています。 特に、私自身がテスタビリティを考える上で重要だと考える、Dependency InversionやDependency Injection (DI), Test Doubleについて詳しく説明し、さらには自分で実装してもらう形をとっています。 Goでは他の言語と違い、デファクトのWeb Frameworkなどはありません(強いて言うなら標準がデファクトで
SWETグループの平田(@tarappo)です。 10/21(木)にiOS Test TeaTime #3を開催しました。 その時の私の登壇資料は次のとおりです。 資料では不足しているであろう情報もあるので、本稿ではその点も補いつつ説明していきたいと思います。 はじめに SWETメンバーとして、プロジェクトに関わるときは「CI/CDサービス」が問題なく動いているかどうかを確認することはよくあります。 CI/CDサービスが文字通り継続的に動いているのであれば「プロジェクトのコードが手元でも動かせる」「コードの状態がある程度わかる」という状態ともいえます。 そのため、これはプロジェクトの状況を把握してなにをするべきかを判断するためには重要な指標の1つともいえます。 その中で最初にチェックする箇所の例としては、次のようなものがあります。 どのようなことを実行しているか 自動テストがあって実行され
はじめまして、2021年に新卒としてSWETに加わったIKです。 今回はSWETに入って感じたこと、思ったことなどを新卒目線で書いていきたいと思います。 IKってどんな新卒? 学生時代にVim scriptばかり書いていた新卒です。 主に、ソフトウェアのメンテナンスに興味をもち、OSSにパッチを送る活動をしていました。 パッチを送った主なリポジトリ vim-airline vim-devicons また、VimConf2019に登壇し、以下の発表をしました。 Grown up from Vim User to Vim plugin developer side しかし、一般的なWebシステムやアプリ開発には疎い、そんな状態で入社しました。 どうしてSWETへの配属を志望したのか 私は学生時代、1からソフトウェアを作ることよりも、ある程度形になったソフトウェアのメンテナンスに参加することの方
こんにちは、SWETでCI/CDチームの前田( @mad_p )です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
こんにちは、Androidチームの田熊(fgfgtkm)と外山(sumio)です。SWETのAndroidチームでは、Androidのプロダクトに対して自動テストのサポートをしています。 この度株式会社Mobility Technologiesが提供するタクシーアプリ「GO」のAndroid版に対する、おおよそ2年間に渡る取り組みが終了しました。 本記事では、この取り組みで行ってきた次の2点を紹介したいと思います。 「GO」のAndorid版に対してどのような自動テストを導入したか 開発チームに自動テストを定着させるまでにやったこと タクシーアプリ「GO」に対しての自動テスト導入 SWETのAndroidチームは「社内のAndroidエンジニアが自動テストを書くことを習慣化している」ことをゴールの1つとして、自動テストを普及させるための取り組みをしています。 その中でAndroidのテスト
SWETグループの長谷川(@nowsprinting)です。 Unity 2020.2以降、Unityエディタ上でRoslynアナライザによる静的解析 (static analysis) を実行可能になりました。 また、それ以前のバージョンで作られたUnityプロジェクトであっても、JetBrains RiderなどのC#向けIDE(統合開発環境)上でRoslynアナライザの実行がサポートされています。 静的解析を充実させることで、コンパイラだけではチェックしきれないようなバグや性能劣化の原因を早期に検出できます。 例えば弊社では、実行時に動的にインスタンス化されるクラスのコンストラクタがIL2CPPビルド時にストリップされないように [Preserve]アトリビュートの指定漏れを検出するアナライザを導入し、ショーストッパーとなりえる問題を早期発見できるようにしています。 通常、こうした問
SWETの加瀬(@Kesin11)です。 先日開催されたiOSDC 2019にて登壇する機会を頂き、「iOSアプリのリジェクトリスクを早期に発見するための取り組み」という発表をしました。 当日は時間の都合上、紹介したツール(以降、AppChecker)がipaをどのように解析し、どのようにチェックを行っているかというロジックの要点だけの紹介しかできず、コードを示した解説まではできませんでした。 AppCheckerは社内の要件やフローに特化した作りとなっているために、残念ながら今のところOSSにする予定はありません。ですが、自分たちと同様のチェッカーを実装したい方が参考にできるように、どのような実装しているのか簡単なサンプルコードで紹介したいと思います。 実装コードの紹介 以下のコードではipa内のInfo.plistからXcodeとiOS SDKのバージョンのチェックを行っています。 #
1. はじめに SWETグループの井口です(@hisa9chi)です。現在はスマホ向けゲーム開発案件にてゲーム開発者がゲーム開発に集中できるようにCI/CD関連を幅広くサポートしています。 本稿では、その中でも Jenkins Pipeline Job で利用可能な Shared Libraries に関して弊社でどのように活用しているか事例を紹介してみたいと思います。 Jenkinsと聞くとおそらく皆さんは、昔は利用していたが今は運用コストが高いなどの理由から、マネージドなクラウドのCI/CDサービスへ移行したという方が多いのではないでしょうか。しかし、ゲーム開発の現場ではJenkins master / agentのクラスタ構成を構築して、運用を続けているプロジェクトが弊社内にも多く存在します。なぜ、運用コストが高いにもかかわらず構築して運用しているかというと、ゲーム開発特有の理由から
はじめに 昨年(2019年)の11月にSWETチームへJoinした伊藤(@akito0107)です。 SWETチームでは主にGoのサービスに対するテスト実装のサポートや品質向上の取り組みを行っています。 この記事では、GoのAPI ServerのRegression Testについて、その目的と低コストに始められるGolden Files を使ったテスト手法をサンプルのコードを交えながら紹介しようと思います。 API ServerのRegression Test Goに限らず、サービスの成長に伴い常に変更が入るようなシステムだと、過去に実装したアーキテクチャが現在の仕様に適さなくなるといったケースも多くあると思います。 そういった場合、Refactoring、Rearchitectingなどを行い、より理想の形へソースコードやアーキテクチャを進化させていきます。その際に重要なのが、 過去の
ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり
はじめに SWETグループGoチームの金子 (@theoden9014) です。 弊社が運営するライブコミュニケーションアプリであるPococha(ポコチャ)においてロードテストを実施する際、Go言語を利用して独自のロードテストツール開発しました。今回は、その知見を共有したいと思います。 この記事はDeNA Advent Calendar 2020の4日目の記事です。 本記事ではシステムをWebシステムと前提としていますのでご注意ください。 ロードテストとは (Load Testing) JSTQBやISTQBにおいては性能テスト (Performance Testing) の1つと定義されています。 性能テストとはシステムテストにおける非機能テストの1つです。 ロードテスト、耐久性テスト、ストレステスト等があり、それぞれ目的に応じて実施します。 ロードテストは、システムがユーザ負荷のピー
はじめに SWETグループiOSチームのkariad(@kariad_uu)です。 本記事はiOSDC 2020 Japanにて発表した「継続的にアプリのパフォーマンスを計測する」の内容を元にブログという形で改めて紹介する記事となります。 発表時のスライドは以下を参照ください。 iOSチームではiOSアプリのパフォーマンス計測に取り組んできました。 iOSアプリのパフォーマンス計測方法はたくさんありますが、中でもInstrumentsを利用したパフォーマンス計測とその自動化について紹介します。 なぜパフォーマンス計測が必要なのか? 取り組んだ計測方法についてご紹介する前にアプリにとってパフォーマンスとその計測がなぜ重要なのかという点を説明します。 起動に時間がかかる、読み込みに時間がかかるアプリは動作が遅くユーザにストレスを与えてしまいます。 短時間で熱くなってしまうアプリでは端末が熱くて
SWETの仕様分析サポートチーム所属のtakasek(@takasek)です。 仕様分析サポートチームでは、社内のプロダクト開発に対する形式手法の活用可能性を模索しています。当ブログでも、継続的に形式手法に関する情報発信をしています(形式手法 カテゴリーの記事一覧)。 当記事は、Kuniwak(@orga_chem)により社内開催されたAlloyガイダンスを元に再構成した記事です。よく知られたデータ構造であるStackを形式仕様記述しビジュアライズすることで、Alloyの使い方と利点を実感できます。Alloy未経験者でもステップバイステップで試せるように構成しました。是非、お手元にAlloyをインストールして読み進めてください。環境はAlloy 5.1.0を想定しています。 https://github.com/AlloyTools/org.alloytools.alloy/release
お久しぶりです。 SWETグループの平田(@tarappo)と片山(@kariad_uu)です。 本稿では、先日オンラインでおこなわれたWWDC2020の中から、SWET視点で気になった次の2点について紹介したいと思います。 The suite life of testing Instruments周り これら以外にもテスト周りの追加としては待望の「Xcodeを用いたStoreKitのテスト」がありますが、本記事では割愛します。 本記事でアップしているXcodeの画像はXcode11.6でとった画像となります。 Xcode12では見た目が変わっている可能性があります。 The suite life of testing まず、WWDC2020で公開された「The suite life of testing」について平田が紹介していきます。 WWDC2020では「The suite life
こんにちは。SWETグループの外山(@sumio_tym)です。 先日、DroidKaigi 2020で発表予定だったセッション「Robolectricの限界を理解してUIテストを高速に実行しよう」 の動画がYouTubeのDroidKaigiチャンネルで公開されました。 新型コロナウイルスの影響でDroidKaigi 2020が中止になってしまったのは残念でしたが、 発表したかった内容を皆さんに伝えることができて、とても嬉しいです。 発表スライドはこちらです。 合わせてサンプルコードも公開していますので、よろしければご覧ください。 さて、本記事では「RobolectricでもUIテストを動かしてみたいけど・・・動画を見る時間がない!」という方に向けて、 ぜひ押さえておきたいポイントを厳選してお伝えします1。 試してみる前に知っておきたいポイント テストがすぐ書ける環境を構築する 工夫が必
次のページ
このページを最初にブックマークしてみませんか?
『DeNA Testing Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く