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は開発者やチームに力（パワー）を与え、高品質のソフトウェアの迅速な開発を実現できると信じます オープンソースソリューションはソフトウェアデリバリのライフサイクル全体を包括的に解決できると信じます コラボレーションと相互運用性を通じてオープンソースのエコシステムやベンダニュートラルなプロジェクトを維持し、育成していきます。 これらの考えを支持し、実践している
至高のCI/CDパイプラインを実現する5つの約束 / The five principles to spark joy in your pipelines - Speaker Deck
Presented virtually at JAWS DAYS 2019.
ぼくの考えたさいきょうの開発フロー - PHP編 - Speaker Deck
Transcript ΅͘ͷߟ͍͖͑ͨ͞ΐ͏ͷ։ൃϑϩʔ PHPฤ Yuta Adachi ࣗݾհ ҆ୡ ༐ଠ (@UAdachi) ! ग़ɿౡࠜݝদߐࢢ ͓ࣄɿChatWork ΠϯϑϥνʔϜ ! ڵຯ͋Δ͜ͱɿυϝΠϯۦಈઃܭɺScalaɺςχε (Οϯϒϧυϯ։࠵த) ! IUUQT���DJSDMFDJ�DPN ͓ॻ͖ • ։ൃϑϩʔΛ࠷దԽ͍ͯ͘͠త • ։ൃڥ • ίϛϡχέʔγϣϯ • CI • σϓϩΠ త ! • ։ൃͷߴԽ • ΦϖϨʔγϣϯϛεͷ༧ • ϓϩμΫτͷ্࣭ + ՄࢹԽ ։ൃڥ Ͳ͏ͬͯߏஙͯ͠·͔͢ʁ • Vagrantͬͯͬͯ·͔͢ʁ ϝϯςφϯε • ։ൃڥͩͬͯߋ৽͞Εଓ͚Δ • ߏஙखॱॻΛ࡞Δͷେม " εΫϦʔϯγϣοτʹҹॻ͍ͯɺઆ໌จΛఴ͑ͯ… ʮԶͷڥʯ ྫ. Aʮಈ͔Ͷʔʯ BʮԶͷڥͩͱಈ͘
Travis CIを利用した継続的な成果物の配置 - すずけんメモ
こんにちは。 @suzu_v です。 Advent Calendar 2015 18日目 休載のお知らせ - VOYAGE GROUP techlog とのことだったので代打で書いてみます。*1 いま私が所属している fluct ではCIの一部にTravis CIを利用しています。用途としては、 継続的なテスト 継続的なビルド というところを担当しています。今日は簡単に、 Uploading Artifacts on Travis CI - Travis CI travis-ci/artifacts の紹介をします。 Travis Artifacts travis-ci/artifacts はTravis CIのアドオンとして利用されているもので、ビルド済みのartifactsを扱うことができます。私たちは一部のバッチやAPIサーバの実装について、Travis CIを利用したビルド及びs3
無料で使える CI サービス 8 個まとめ - 永遠に未完成
CI サービスをいくつか触ってみたのでまとめ。 今回の目的は、テストを実行すること。なので、ビルドやデプロイ辺りはちゃんとは見ていない。 ドキュメントで確認しただけの項目などもあったりするので、間違っていたらごめんなさい。教えてもらえると助かります。 ただ、これは記事を書いた時点での比較で、今後のサービスの変更に対応する予定はないです。 触ってみたサービス一覧 アルファベット順。 AppVeyor CircleCI Drone IO Magnum CI semaphore shippable Travis CI wercker codeship ってのもあったけど、無料プランは月100ビルドまでとかで常用には耐えないと感じたので中身見てない。 機能比較 機能比較は全て無料プランでのもの。有料だと対応している場合でもここでは x にしている。 比較項目は私の独断と偏見で適当に選出した。 項目
チャット経由でデプロイする - Qiita
最近開発で利用している、デプロイをチャット経由で行うフローについて説明します。 要点 開発者はmasterブランチで開発する 開発者はデプロイしたいときにBotにお願いする Botはmasterブランチからproductionブランチに対してPull Requestをつくる 開発者はPull Requestを確認してmergeする CIはproductionブランチが変更されるとサーバにデプロイする ChatOps masterブランチからproductionブランチにPull Requestを出す作業は面倒なので、チャット経由で行っています。Heroku上で動かしたRubotyにruboty-githubとruboty-aliasというプラグインを入れて、「デプロイしたい」と発言するとPull Requestを作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育
レガシーコード改善勉強会 開催レポート
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27（土）の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード（テストコードが無いコード）と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 ＜開催趣旨・目的＞ テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、
Slack / Hubot / GitHub / CircleCI によるChatOpsなデプロイ方法 - Qiita
概要 Slack / Hubot / GitHub / CircleCI などをつかってChatOpsにチーム開発できるフローをつくったので、ChatOpsによるデプロイ方法を中心にその方法をまとめてみます。 ChatOpsの主役であるチャットアプリには今回Slackを使いました。 HipChatでも同じように出来ますが、Slackの方がUIが優れていており、外部サービスとの連携も洗練されていたのでこちらを選択しました。 ChatOpsな環境の概要 SlackとHubot（PaaSであるheroku上にデプロイ）を連携させる SlackからHubot経由でGitHubにプルリクエストをつくる GitHub上の変更を監視し、CircleCIでテストを実施 デプロイ用のブランチに変更があった場合（GitHubのWEBコンソールでデプロイ用ブランチへのプルリクエストをマージした場合）、Circl
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
Githubエコシステムを活用したイマドキの趣味開発 - くりにっき
社内でLTする機会があったので資料を公開します Githubエコシステムを活用したイマドキの趣味開発 from Go Sueyoshi (a.k.a sue445) バックグラウンド 実はこれは先日同僚がRubyKaigi2014で発表した "Gem of this Week" - building culture and making gem のカウンターエントリだったり、補足だったり、そんな感じです。 登壇者のエントリ: RubyKaigi2014で発表した - mitaku.log 残念ながら社内版のcodeclimateやcoverallsに相当するものはないので、業務ロジックや社内のコンテキストが絡まないところに関してはgithubで公開してしまった方がいろいろなエコシステムを活用できると思ってます。 社外に出すとなると 英語でコメント書く issueやPRで英語やり取りが発生す
jenkins で GitHub のプルリクエストをマージしてテストする
GitHub pull request builder plugin - Jenkins - Jenkins Wiki GitHub pull request builder plugin を使うと、 プルリクエストを自動でマージしてテスト 結果を GitHub の Status API で通知 プルリクエストにコメントしてテストをリトライ などということができる。 設定手順 設定手順は他のシンプルなプラグインに比べてちょっと複雑。 ボットユーザの作成 事前にボット用のユーザーを作成して、対象のリポジトリのコラボレーターとして登録しておく。このボットユーザーがプルリクにコメントしたりするので、アイコンをそれっぽくしておくと楽しい。 全体の設定 プラグイン全体の設定をする。ここの設定がデフォルトとなり、プロジェクトごとに上書きして使う。 Jenkinsの管理 -> システムの設定 -> Gi
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
Infrastructure as Code - naoyaのはてなダイアリー
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
転職してから半年くらいでやったことまとめ - Perl日記
IRCを導入した 遠隔地で作業しているひともいた中でメールでのやりとりはとても面倒だった。 (同じオフィスで開発してるひとからもメールでいろいろ来た) だるかったので、ngIRCdを導入して、やりとりがすごく楽になった。(基本英語だが) リポジトリを分割した サーバに置いてあるものがすべて1つのリポジトリで管理されていた。(僕は泣いた) だるかったけど、頑張って適切なサービスの単位で分割した。 ファイルサーバ作った クラウドに置かないほうがいいファイルとか共有するため。 ユニットテスト直した ぶっ壊れていたのをとりあえず動くようにしてから、とにかく自分が触るところを中心に追加していった。 カバレッジが最初は30%くらいだったけど、いまは90%近くまで上がっていて、 僕に多少の精神的な安寧をもたらしてくれている。 Pull Reqestベースの開発にした それまでは(ローンチ後も)maste
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
プロセスやルールはどうする？
難関1で示したCIの流れは、あくまでツールの処理である。CIではさらに、開発者が行うプログラミングなどを含めたプロセスやルールが必要になる。これが、二つ目の難関である。 もともとCIは、アジャイル型の方法論の一つである「XP（eXtreme Programming）」で提唱されたプラクティスである。このため短い期間で開発・テスト・実装を繰り返すアジャイル型の開発プロセスと相性がよい。というより、アジャイルではCIの導入はほぼ必須だ。とはいえ、ウォーターフォール型の開発プロセスには適用できないかといえば、そんなことはない。ウォーターフォール型でも導入は可能で、同様のメリットを得られる。 基本的に、アジャイル型とウォーターフォール型でCIのプロセスやルールに違いはない。ただしデリバリーまで含めたCD（Continuous Delivery：継続的デリバリー）と呼ぶ手法を実践する場合はアジャイル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Advanced Continuous Delivery Best Practices (DEV317-R1) - AWS re:Invent 2018
パイプラインベースのCI/CDツール Concourse CI入門 - BLOG.IK.AM
RCOアドテク部勉強会：イノベーションと開発プロセスってタイトルで発表しました | RCO Ad-Tech Lab Blog