GitHub Actions & ecspressoによるデプロイフロー構築 - コネヒト開発者ブログ
こんにちは、リードエンジニアの @dachi_023 です。今回はGitHub Actionsとecspressoでデプロイフローの構築をしたのでそれについて書いていきます。先に言っておくと簡単にセットアップできるし設定もシンプルなのでかなりおすすめです。 Actions | GitHub kayac/ecspresso: ecspresso is a deployment tool for Amazon ECS これまでのデプロイ コネヒトではECS環境へのデプロイに silinternational/ecs-deploy を採用しています。CodeBuildもしくはTravis CI上からecs-deployを利用してECS環境にアプリケーションをデプロイする構成です。 CI/CDツールの乗り換え検討 これまでずっとTravis CIを利用してきました。しかし 料金体系の変更 があった
【2021年版】GitHub × Go製ツールのリリースフロー
はじめに GoでCLIをよく作る身として、 どのように素晴らしいリリースフローを構築するか に心を砕いています。 2019年末にリリースされたGitHub Actionsがすっかり成熟し、GitHub Container Repository(β)もお目見えとなった2020年も暮れを迎えたところで、新たなリリースフロー構築を検討し、一定の結論を得ましたので、少しでもGophersのたすけになることを願って、記事として公開します。 背景 実現したい「リリース」 クロスコンパイルしたバイナリでの配布 Goでツールを作ることで、クロスコンパイルの手軽さによって、様々な環境で、ダウンロードすればすぐに実行できるバイナリでの配布が可能です。 $ curl -O bin.tar.gz https://github.com/kyoh86/gogh/releases/download/v1.7.1/gog
Docker で「速くてウマイ」な CI 環境を構築するための 5 つの Tips | 株式会社ヌーラボ(Nulab inc.)
Docker 社のユースケースでもあげられているように、CI/CD で Docker を使うというのは、プロダクションシステム以外で Docker の特性を活用できる良い場所だと考えています。ヌーラボではBacklog でのプルリクエストの提供以降、CI のジョブの実行のために Docker を利用しています。ここではその運用から学んだ５つの Tips を紹介したいと思います。 ヌーラボの CI 環境の全体図 これがヌーラボの CI 環境の全体図です。 CI には Jenkins を利用しており、Jenkins のジョブのトリガーとなるのは左側の Backlog や Typetalk です。実際には Jenkins Backlog Plugin や Jenkins Typetalk Plugin を利用してジョブを処理しています。これらのプラグインの詳細については本ブログ末に参照先をのせて
チャット経由でデプロイする - 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を作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育
Railsアプリのステージング環境を自動で構築してくれるTeatroというサービスの話。 - Sooey
Railsアプリのステージング環境を自動で構築してくれるTeatroというサービスの話。 Teatro 動作の流れは、 GitHubアカウントでサインアップする 連携させるリポジトリを選ぶ（GitHub側にフックが設定される） リポジトリにPull Requestが作成されると、自動的にステージング環境の構築が始まる（その際、PRにもコメントがされる） ステージング環境の構築が完了すると、http://ブランチ名.Organization名-リポジトリ名-トークン.ttrcloud.com/ のようなURLが割り当てられる といった感じ。 詳細な設定方法やどんなミドルウェアが使えるのかについては、Helpを参照しましょう。 現時点では以下のミドルウェアが使えるようです。 PostgreSQL MySQL Redis Elasticsearch RabbitMQ MongoDB 試しに、He
Your platform for software quality management
Continuous Integration Integrate and deploy your applications
PHPerな僕が最近気になるCIツールを調べてみたよ2014春 - polidog lab++
最近だとCI使って自動テストしてます系の会社も多いのかと思います。 有名なCIとしてあるのはjenkinsがありますよね。ただ最近はJenkins以外のツールも出てきています。 そこで、ここ最近CIツールがいくつか出てきたので調べてみました。 そもそもCIツールとは？ 継続的インテグレーションを自動化するためのツールであるわけで、テストの自動化とかビルドの自動化とかが中心なツールですよね。 まあ僕はWebアプリケーションエンジニアと呼ばれるクラスタなので、ユニットテストの自動化とpushしたタイミングとかで自動的にやってくれる便利なツールぐらいの認識ですが・・・ 最近は様々なCIツールができてました。webサービスとしてでているのでCIツール用のサーバを用意したりってのもいらなくて非常に便利です。 あといろいろな言語に対応してたり、yamlで簡単に設定書けばいいとかJenkinsに
ぼくの考えたさいきょうの開発フロー - PHP編 - Speaker Deck
Transcript ΅͘ͷߟ͍͖͑ͨ͞ΐ͏ͷ։ൃϑϩʔ PHPฤ Yuta Adachi ࣗݾհ ҆ୡ ༐ଠ (@UAdachi) ! ग़ɿౡࠜݝদߐࢢ ͓ࣄɿChatWork ΠϯϑϥνʔϜ ! ڵຯ͋Δ͜ͱɿυϝΠϯۦಈઃܭɺScalaɺςχε (Οϯϒϧυϯ։࠵த) ! IUUQT���DJSDMFDJ�DPN ͓ॻ͖ • ։ൃϑϩʔΛ࠷దԽ͍ͯ͘͠త • ։ൃڥ • ίϛϡχέʔγϣϯ • CI • σϓϩΠ త ! • ։ൃͷߴԽ • ΦϖϨʔγϣϯϛεͷ༧ • ϓϩμΫτͷ্࣭ + ՄࢹԽ ։ൃڥ Ͳ͏ͬͯߏஙͯ͠·͔͢ʁ • Vagrantͬͯͬͯ·͔͢ʁ ϝϯςφϯε • ։ൃڥͩͬͯߋ৽͞Εଓ͚Δ • ߏஙखॱॻΛ࡞Δͷେม " εΫϦʔϯγϣοτʹҹॻ͍ͯɺઆ໌จΛఴ͑ͯ… ʮԶͷڥʯ ྫ. Aʮಈ͔Ͷʔʯ BʮԶͷڥͩͱಈ͘
Walti サーバーサイドのセキュリティ スキャンを身近に
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.
Emacsがこの先生きのこるためのたった1つの方法 - Qiita
仮想環境技術の進歩によりVagrant、Chef、Ansibleなどのツールを用いて、 サーバーの環境構築を今までの手作業的なものからソースコードで記述していこうという流れがある。 これらに纏わる技術はサーバーの本番運用に関してのトピックがメインだけども、 サーバーのセットアップが自動で行えるようになれば開発環境のセットアップも そうなっていくのは自明で、VagrantでローカルにUbuntuを入れて開発に利用する なんてことは既に多くの人が行っているはず。 そういうことをしていると、必然的に環境ごとにエディタの設定なども行わなければならない。 必要とされるのは、冪等性のあるワンストップかつ自動でインストールさせることが出来る手段だ。 emacsの場合、リモート先のファイルを編集するためのTrampという優れた機能が存在するため、 必ずしもサーバー側にエディタが存在している必要はないのだけ
Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
ワンクリックデプロイ101 #ocdeploy
2011年12月20日に実施したワンクリックデプロイ勉強会の資料です。 http://www.ryuzee.com/Read less
%25E3%2581%25AB%25E3%2581%25A4%25E3%2581%2584%25E3%2581%25A6%25E3%2581%258A%25E8%25A9%25B1%25E3%2581%2597%25E3%2581%2597%25E3%2581%25BE%25E3%2581%2597%25E3%2581%259F)
DevLOVEでJenkins(というかCIとインフラ)についてお話ししました - けんちゃんくんさんのWeb日記
同僚の@papandaからの依頼とあれば断わる理由はないので、DevLOVE HangarFlight - Snow Barrage -で、Jenkinsを中心としたCIとそのインフラについてお話ししてきました。 Jenkins勉強会で発表した内容に、それから半年の動きを足した内容となっています。 主たるコミュニケーションツールであるIRCを中心として開発者が開発に集中できること 有限のサーバリソースをどう使って快適なCI環境を手にいれるか ということが、ここ1年くらいホットなトピックだったので、そのために私たちがやっている取り組みをお話させていただきました。 何人かの方から、JenkinsとIRCと会話するのは面白い、GanetiやTravisは知らなかったけど興味が湧いたという声を頂いて、発表してよかったなぁと思いました。 また、懇親会では、Vundleの記事やWeb+DBの特集がよか
きっと何者にも成れないモジュールたちに告げる~静的解析、しましょうか~ - mixi engineer blog
たんぽぽグループのhirokiです。たんぽぽグループとはmixi内の「刺身にたんぽぽをのせる仕事をなくす」ことを目的とした技術者集団です。 「あれは、たんぽぽではない食用菊である」 「スーパーの生鮮食品バックヤードが片手間にやってるよ。」 というご批判・ご指摘をうけ、今後は「道路に片方だけの軍手を落とす仕事をなくす」ことを目的としていこうかなどの検討を重ねました結果、「細けぇこたぁいいんだよ。」という結論に至ったことをこの場を借りてご報告させていただきます。今後ともたんぽぽグループを御ひいきによろしくお願いいたします。 と、ご報告をさせていただいたところで、本題にはいります。 YAPC::Asia Tokyo 2011 先日Perlのお祭りことYAPC::Asia Tokyo 2011においてLTをさせていただきました。その資料のご紹介とちょっとした解説をさせていただきます。 静的解析、し
symfony + jenkins でテストサイクルを回そう | ウェブインパクトエンジニア IT番長ブログ
テスト大好き、WIのコックさんです。 テスト好きですか？単体テスト書いてますか？ 引き続き自分からは、テストネタを一つ。 弊社ではsymfonyを利用して開発を行うことが多いのですが、symfony + jenkins でテスト環境を整える方法を簡単にご紹介したいと思います。 まず、既にsymfonyプロジェクトが存在している前提で話を進めます。symfonyについての詳しい説明は公式の素晴らしいマニュアルをご参照下さい。 http://www.symfony-project.org/ また、この記事を書くために用意した環境は以下の通りです CentOS5.5 / java1.6.x / PHP5.3.x / mysql 5.5 / svn1.6.x / symfony1.4 / jenkins1.4 <1> jenkinsのインストール jenkins とは、JavaベースのCI(継
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
FitNesse+Selenium+Jenkinsによるテストケース継続的インテグレーション（１）
今回は、JaSTT'11 Tokyo のコープランド氏の講演で紹介されていたFitNesseのお話をしたいと思います。
GitHubのdefunktが作ったCIサーバ cijoeは、とても簡単に使えるので小さなプロジェクトではおすすめ（Jenkinsのような充... - Sooey
GitHubのdefunktが作ったCIサーバ cijoeは、とても簡単に使えるので小さなプロジェクトではおすすめ（Jenkinsのような充実機能はありません）。 ためしに、巷で話題のamatsuda/kaminariのテストをcijoeで実行してみましょう。 まずはcijoeをインストール。 $ gem install cijoe 手元のSnowLeopard + Ruby 1.9.2だとkaminariのbundle install中にlinecacheのインストールでコケてしまうので、1.8.7を使います。 $ ruby -v ruby 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin10.5.0] まず、ビルド対象のリポジトリをローカルに持ってきて、rake specが成功するところまで確認します。 $ git clone https:/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Buddy: The DevOps Automation Platform
Ciしてるかい？