僕たちとECSとデプロイとその改善 | 株式会社ヌーラボ(Nulab inc.)
みなさんこんにちは。Backlog課のGitチームに所属するテリーです。今回は僕たちが日々運用するECS Fargate上のアプリケーションのデプロイ方法とそれをどう改善してきたかについてまとめました。デプロイについて迷っている方や日々の業務の改善が好きな人に読んでもらえたらと思います。 Git機能におけるデプロイ ECS上で動くアプリケーション BacklogのGitはEC2上で動くアプリケーションとECS Fargate上で動くアプリケーションで構成されています。 アーキテクチャの外観は上記のようなになっています。Gitのアーキテクチャについて過去に詳しく説明したブログを発表していますので詳しくはこちらを参照ください。 僕たちは上記のアーキテクチャ中の4つのアプリケーションをECS Fargate上で運用しています。また、内部的な話になりますがBacklogには内部構造として複数の本番
reviewdog x perlcritic x Jenkins で最高の GitHub レビューライフ - Mirrativ Tech Blog
ミラティブのサーバーサイドエンジニア、ハトネコエです！ 今日は、GitHub の自動レビューとして reviewdog を導入した話をします。 1. 動機 すでに CTO の夏さんによって、Perl 用の linter である perlcritic が導入されていました。 そして、テストが走る際に perlcritic のチェックもおこなわれ、 指摘箇所があればテストが落ちるようになっていました。 まずは緩めの設定で導入したけれど、perlcritic のチェックをもっと厳しくしたい！ だけど厳しくすると、すでに存在するコード（つまり、プルリクで変更していない部分）が原因で テストが落ちるようになってしまいます。 残念ながら perlcritic には autofix の機能も無いようで、 設定を変更した後は、人力での修正が終わるまでテストは落ち続けてしまいます。 これでは開発に支障が出る
エンドツーエンドテスト(E2Eテスト)をTestCafeとAWS CodeBuildでもっともっと手軽にする - RAKSUL TechBlog
ラクスルの@nnm_techです。 ラクスルの印刷サービスではこれまでにもE2Eテストがありましたが、この度より良いシステムを目指し再構築することになりました。 本記事ではTestCafeとAWS CodeBuildを用いたE2Eテスト刷新について紹介したいと思います。 ラクスルで運用している印刷サービスは裏側で複数のサービスが協調動作しています。 入稿サービス、発注サービス、決済サービス…外部サービスとの連携も含めるとかなりの数があります。 このような中、弊社では各サービスの変更時におけるユースケースの動作担保・リグレッション検知を目的にE2Eテストを実施しています。 目次 E2Eテストを構築するにあたってのポイント ポイント1: テストの書きやすさ ポイント2: 実行環境の問題 ポイント3: 実行タイミング これまで どうしたか テストの書きやすさ: TestCafeの導入 実行環境:
はてなでのKubernetes利用の取組み - Hatena Developer Blog
こんにちは、入社 3 年目の SRE の id:kizkoh です。 今年から別のチームに異動になったのですが、以前は Mackerel チームで仕事をしていました。 このエントリでご紹介するのは私が以前担当していた Mackerel での Kubernetes(k8s) クラスタ利用の取組みになります。 はじめに 入社してから約 2 年間 Mackerel チームでサービス運用開発の仕事をしていました。直近のトピックでは 2 月に公開された Mackerel コンテナエージェントの開発、検証のお手伝いとして k8s クラスタでの検証や Mackerel のシステムのコンテナ運用として k8s クラスタ基盤の設計構築に取り組んでいました。 昨年 2018 年は国内で Japan Container Days (今年からは CloudNative Days です)が開催され k8s のトピッ
テスト作業も、画面キャプチャによるエビデンス取得も自動化してくれて、Jenkinsとの連動も可能。Web、デスクトップ、モバイルに対応するテスト自動化ツール［PR］
テスト作業も、画面キャプチャによるエビデンス取得も自動化してくれて、Jenkinsとの連動も可能。Web、デスクトップ、モバイルに対応するテスト自動化ツール［PR］ ソフトウェアのテストは、アプリケーションの開発時や受け入れ時などさまざまな場面で必要とされています。最近ではWindowsやiOSなどのOSやGoogle ChromeなどのWebブラウザが以前よりも頻繁にアップデートを行うようになったことで、アップデート時における既存アプリケーションの動作確認のためのテストもニーズが高まっているようです。 こうした増えてきたソフトウェアテストの実行に欠かせないのが、自動化ツールです。 テスト自動化ツールで実現したいこととは？ 一般にソフトウェアテストの自動化ツールは、ユーザーのマウスやキーボード操作を記録し、再現したり、あるいはテストスクリプトに沿って人間のような操作を自動的に実行してくれる
JenkinsやSpinnakerなどの開発をホストする「Continuous Delivery Foundation」発足。CI/CDの普及とエコシステムの発展を促進
JenkinsやSpinnakerなどの開発をホストする「Continuous Delivery Foundation」発足。CI/CDの普及とエコシステムの発展を促進 Linux Foundationは「Continuous Delivery Foundation」の設立を発表しました。 Continuous Delivery Foundationは、次の4つの価値を基本原則とするとされています。 Continuous Deliveryは開発者やチームに力（パワー）を与え、高品質のソフトウェアの迅速な開発を実現できると信じます オープンソースソリューションはソフトウェアデリバリのライフサイクル全体を包括的に解決できると信じます コラボレーションと相互運用性を通じてオープンソースのエコシステムやベンダニュートラルなプロジェクトを維持し、育成していきます。 これらの考えを支持し、実践している
開発支援サーバー(GitBucket、Redmine、Jenkins)を退役させてSaaSに移行させた話 - ZOZO TECH BLOG
こんにちは。ZOZOテクノロジーズ開発部の田島です。 今時のシステム開発ではさまざまなツールを利用することが当たり前になっています。 そして各種ツールは日々新しいものが開発され、今まで当たり前だったものがレガシーなツールと呼ばれることも珍しくありません。 弊社では、GitHubやCircleCI・Slackなど様々なツールを利用しています。 私達のチームでもこれらのツールを利用していますが、それ以外にもGitBucketやJenkins・Redmineを独自で管理し利用していました。 今回ある理由からそれらのツールをSaaSへ移行しました。その経緯と移行手順を紹介します。 概要 開発支援サーバの紹介 利用しているGitBucket・Jenkins・Redmineは開発支援サーバと呼ばれる一台のEC2インスタンスの上で動作していました。 やったこと これらのツールを以下の図のように、「Git
CIマニアから見た各種CIツールの使い所 - くりにっき
社内外でちょいちょい聞かれるのでメモ。 前置き GitHubを使ってる場合 ライブラリを作ってる場合 Travis CIを選択する理由 2020/4/21追記 Travis CIを選択しない理由 アプリを作ってる場合 CircleCIとWerckerの共通点 CircleCIとWerckerの機能差異 GitLabを使ってる場合 GitLab CIの優位点 Jenkinsなどを使った方がいい場合 追記：2018/12/8 前置き 100%自分の主観なので偏ってます SaaSかオンプレならSaaS派。（自分でサーバの面倒身たくない） 自分が使ったことがないものは紹介していません 今回紹介してるTravis CI, CircleCI, Wercker, GitLab CI, Jenkinsに関しては仕事や趣味で各3〜4年くらいは使ってるはず GitHubを使ってる場合 ライブラリを作ってる場合
Bitrise と fastlane で作る高速 CI/CD 環境 #Zaim｜watura
これらのツールを組み合わせて、以下の作業を自動化しています。 Danger の実行 テストの実行 DeployGate への配信 App Store へのアップロード（１）Danger の実行Pull Request の簡易チェックツールである Danger を使って、Pull Request の一次確認を実行しています。 Danger は旧 CI マシンである Jenkins から起動しています。Jenkins である理由は、「Pull Request の本文やタイトルに変更があった場合、そのコメント欄に "danger please" と書き込むことで、Danger に再チェックしてもらいたい。これは、今のところ Bitrise ではできない」という事情があります。 例えば Zaim の iOS 版では「Pull Request のタイトルに必ず呼応する issue 番号を入れる」とい
CircleCIのPerformance Planが控え目に言って最高という話 | Money Forward Engineers' Blog
こんにちは。18新卒でサービスインフラチームの小笠原 (@0gajun) です。 今日はCircleCIのPerformance Planを用いて、CI環境の改善を行った話をします。 （決してCircleCIの回し者ではありません :wink: ） Summary 今までJenkinsをCI環境として用いており、様々な問題を抱えていた CI環境を改善するためにCircleCIに移行した CircleCIにはPerformance Planという従量課金プランが存在する コンテナの並列実行数に制限がなく、実行時間ベースでの従量課金 ただし、まだ Early Accessの段階。 JenkinsからCircleCIに移行することで、次のメリットが得られた CI時間の短縮 CIジョブがキューイングされる問題からの開放 CI環境のメンテナンスコスト削減 CIコストの削減 CircleCIのPerf
AWS FargateとDocker Composeで簡単分散RSpec | GREE Engineering
AWS Fargate早く東京に来てくれという願いをこめて、東京で1つでも事例を増やそうと記事を書いていたら公開する前にAWS Fargateが東京に来ることが先日発表されました！めでたいです。アリネ事業部の平田です。 今日はARINEで使っていく(かもしれない) AWS Fargate を使ったRSpecの実行環境の話と、Docker Compose使っているならFargateいいかもしれませんよ、という話をします。 背景 アリネ事業部では、なりたい自分がきっと見つかる美容メディア ARINE を運用しています。 ARINEのサーバサイドはRubyで書かれており、ウェブアプリケーションフレームワークはRuby on Railsを採用し、テストにはRSpecを使っています。 テストは徐々に増えており現在テストが1000件ほどで、テストにかかる時間も徐々に長くなり、完走するのに10分以上かか
リクルートライフスタイルにおける Frontend Ops の取り組みとその中で開発した OSS 「status-back」の紹介
リクルートライフスタイルにおける Frontend Ops の取り組み とその中で開発した OSS 「status-back」の紹介 Airシリーズのフロントエンジニア日野澤 (@kt3k) です。今日はリクルートライフスタイル Airシリーズのフロントエンドチームで行なっている Frontend Ops の取り組みを紹介させて頂きます。また、その過程で開発した OSS ツール status-back について紹介します。 (なお本稿では、Frontend Ops とは Frontend における DevOps の取り組み、すなわち各種ツールチェインや自動化手法を用いて、フロントエンドにおける開発及びデリバリーパフォーマンスの向上を行う手法及びその実践と定義します。参考1, 参考2) Jenkins による lint / テスト / モックビルドの自動化 Airフロントエンドチームでは、数
「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化
「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化 ソフトウェアの開発プロセスにおいて、「Jenkins」はビルドやテスト、デプロイなどを自動化してくれるツールとしてよく知られています。 そのJenkinsの派生プロジェクトとして、「Jenkins X」が発表されました。Jenkins Xは、Git、Docker、Kubernetesの環境を前提とすることで、Jenkinsの設定、運用などを大幅に自動化し、より簡単な導入と運用を実現するものです。 Jenkins Xは、Git/Docker/Kubernetes環境に特化 オリジナルのJenkinsは汎用的なビルドやテストの自動化ツールとして、さまざまな環境やツールと連係できるように作られています。そのため柔軟なコンフィグレーションが可能になっていますが、一方でそれが導入や
Androidアプリ開発向けの横断CI環境
こんにちは、スマートデバイス基盤チームの段です。 スマートデバイス基盤チームでは、リクルートライフスタイルのスマホアプリ開発における開発標準・品質指標の策定、新技術の検証及び横断推進、また、可視化及びCIシステムの運用改善など横断ミッションを担っています。 継続的インテグレーション（CI）はアプリ開発プロセスにおける重要な一環で、そのシステム運用改善を横断チームで実施するか各サービス側で実施するかの選択肢があると思いますが、弊社ではスマートデバイス基盤チームが担当しています。日頃の安定運用も勿論ですが、サービス側要件の柔軟対応、CIノウハウの属人化回避、運用工数削減などを意識した改善活動を積極的に行っています。 本記事では、現在運用しているAndroid向けのCI環境をご紹介します。 全体構成 ビルド処理〜配布はジョブ毎にDockerコンテナで実施 Jenkins Pipelineを導入し
GitHub + Jenkins で、全てのプルリクエストに対してレビューとテストを必須にする - Qiita
最近関わった某OSSの真似をして、GitHubプロジェクトでプルリクエスト（PR）のレビューと自動テストを必須にしたいと思い、ドキュメントを適当にググりながら設定してたのですが、書いてる内容が古かったりしてやたらこんがらがり、1日仕事になってしまいました。 ということで、自分はこう設定したというメモを残します。まぁこれもほっとくとすぐ古くなりそうですが。 やりたいことは、以下の通り。 masterブランチPR発行時、然るべき人にレビューのリクエストが飛ぶようにする 同時に、Jenkinsでテストも実行される レビューとテスト、両方が通らないとmasterにマージできないようにする まずはレビューを必須に レビューを必須にするのは、GitHubだけで設定可能です。以下説明。 GitHubプロジェクトを作るところは省略します。ここでは、bonotake/rvtest なるリポジトリをこさえたと
JenkinsにHeadless Chromeを入れて定期的にスクショをSlackに投げデザイン崩れがないかチェックする - Qiita
Headless Chrome（ヘッドレス Chrome)がついに、Chrome 59に搭載されました。 GUIのないLinux環境でも簡単にChromeが実行できるようになりました。 これでリリース後にデザイン崩れをチェックしたり、毎日のサイトチェックなんかにも利用できます。 試しに、Yahoo! JAPANのトップのニュース確認という体で毎時にスクショを撮ってみます。 Google ChromeをUbuntuにインストール 今回はUbuntuの環境だったのでapt-getを使います。 apt-getでChromeをインストールできるようにする $ echo "deb http://dl.google.com/linux/chrome/deb/ stable main" | sudo tee -a /etc/apt/sources.list deb http://dl.google.co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デプロイ頻度を10倍にした、ブランチ戦略とGitHub Actions on AWS ECS
Jenkinsの現代化と'Jenkinstein'回避のための5つの取り組み
テレビ・レコーダーのバックエンドにおけるCI/CDへの取り組み
ECS Fargate build on AWS CodeBuild
