はじめに 1から簡単なAndroidアプリを作成し、それに対するE2EテストをAppiumで自動化しCI環境で実行できるようにする所までをやってみたのでその備忘録を残しておく。 ※本記事はwebdriverioを用いているが、あえて最小で構築しているので@wdio/cliは利用していない。 構築したアプリ・e2e自動テストのコード・CIパイプラインのコードは以下のGitHubにある。 内容 セクションは大きく3つで、 アプリの実装について(Androidアプリを作成する) e2eテスト自動化のソースコードの実装について(AppiumによるE2Eテスト) CI上での自動テスト実行について(CI) に分かれている。 Androidアプリを作成する アプリの実装 Androidアプリのdeveloper向けのサイトにある公式チュートリアルがステップバイステップで丁寧&日本語字幕・解説があるので、
CircleCIから提供されているAndroidのDockerイメージを使用している場合、使われるbuildToolsVersionの一覧がdockerfilesに書かれているみたいです。 例えば api-30を使う場合、👇 RUN sdkmanager \ "build-tools;27.0.0" \ "build-tools;27.0.1" \ "build-tools;27.0.2" \ "build-tools;27.0.3" \ # 28.0.0 is failing to download from Google for some reason #"build-tools;28.0.0" \ "build-tools;28.0.1" \ "build-tools;28.0.2" \ "build-tools;28.0.3" \ "build-tools;29.0.0" \ "
はじめに 記事内容 私は現在、バックエンドエンジニアを目指し、転職活動中です。 今回はCircleCI導入時、bundle installが実行されないエラーが発生したので、その解決方法について執筆します。 開発環境 Ruby 2.7.2 Rails 6.1.4 Docker 20.10.6 MySQL 5.7.32 bundler 2.2.23 CircleCI 2.1 CircleCIによる自動化項目 RuboCop RSpec .circleci/config.yml version: 2.1 executors: default_container: docker: - image: circleci/ruby:2.7.2-node environment: RAILS_ENV: test BUNDLE_JOBS: 4 BUNDLE_RETRY: 3 BUNDLE_PATH: ve
Runtrip社で複(副)業(以後は複業で統一)を始めて、早いもので2年半が経とうとしております。 そこで、この記事では複業という業務形態でどんなことをしてきたのかを備忘録的に振り返ろうと思います。 そのため、この記事は下記のような方にお役に立てれば幸いですmm ・複業とか流行ってる?みたいだけど、世の中ではどんなことを複業でやってんだろ?(特に開発) ・Runtripって複業とかで関われるんだ!でも実際はどんなことやってんの?(特に開発) (もちろん、複業には色々な形があるので、あくまで1つの事例として^^) 背景Runtripで複業を始めたきっかけは下記の記事にまとまっておりますので、ご興味ある方は是非mm その複業を始める上で、自分が考えたこと、かつRuntrip社と期待値合わせしたこと等に関しては こちらの記事 に記載しておりますので、ご興味ある方は是非Part2。 複業のイマRu
こんにちは、バックエンドグループの冨永と申します。 弊社のタクシーアプリGO にはGAE Standard 1st Go1.11を使用しているAPIサーバーがあり、このサーバーの2nd Go1.12以上への移行を計画しています。 他サイトでもGAE 2ndへの移行記事が増えてきましたが、実際に取り組んでみると新たに得られた知見がありましたので共有したいと思います。 移行計画1stのGo1.11は1st用のappengineパッケージと2nd対応のパッケージが併用できるため、少しずつ置き換えていくことができます。タイトルが 移行準備 となっているのはこれが理由です。 現在は一部のAPI endpointだけ移行しており、残りのendpointを動作確認しつつ移行していく予定です。 urlfetchの置き換えnet/httpのClientに置き換えるだけですが、デフォルトのtimeoutが設定
スマートキャンプ、エンジニアの入山です。 前回のブログで、弊社プロダクトのインフラをEC2基盤からECS/Fargate基盤へ移行した話を紹介しました。 tech.smartcamp.co.jp 上記プロジェクトは大規模なインフラの刷新だったこともあり、CI/CDについても従来の仕組みからECS/Fargateの構成に合わせて変更しています。 CI/CDは、安定したプロダクト開発には必須且つ長期に渡って継続的に利用するものなので、いかにストレス少なく効率的に出来るかが重要だと考えています。 また、CI/CDは一度構築してしまうと放置されがちですが、日々の開発チーム全体の生産性にも大きな影響を与えるため、こういった数少ない再構築のタイミングではコストを掛ける価値があるのではないでしょうか。 今回は、弊社のインフラ移行時に実施したCI/CDの改善について紹介したいと思います。 従来のCI/CD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く