#hashi_wantedly
Many development teams have found the microservices architectural style to be a superior approach to a monolithic architecture. But other teams have found them to be a productivity-sapping burden. Like any architectural style, microservices bring costs and benefits. To make a sensible choice you have to understand these and apply them to your specific context. Microservices provide benefits… Stron
Go has been designed as a backend language and is mostly used as such. Servers are the most common type of software produced with it. The question I’m going to answer here is: how to cleanly upgrade a running server? Goals: Do not close any of the existing connections: for instance, we don’t want to cut down any running deployment. However we want to be able to upgrade our services whenever we wan
http://herokujp.doorkeeper.jp/events/10902
Gitでバージョン管理をしていると、本番サーバにデプロイする際に、クライアントでpush、そして本番サーバにログインしてgit pull、ってやるのは面倒臭いですよね。そんな不毛な操作は自動化するのがプログラマとしては当然です。 GitHub上のリポジトリで、デプロイの自動化をやるにはWebhookやTravis CI、JenkinsなどのCIツールとの連携を考えます。選択肢は多々あり、それぞれにメリット、デメリットはありますが、今回は後々、FuelPHPのユニットテスト自動化までを見据えて、Jenkinsによるデプロイ自動化を試してみようと思います。 サーバ構成イメージ 今回、Jenkinsを導入するにあたって、専用のEC2インスタンスを立ち上げます。このインスタンスをCIサーバとして利用していきます。 GitHubリポジトリへプッシュされたとき、GitHubはJenkinsサーバへ通知
Top Announcements of the AWS Summit in New York, 2023 It’s probably no surprise that generative artificial intelligence and machine learning were the stars of the show, but there were several other bright lights from the day-long cloud conference. New Seventh-Generation General Purpose Amazon EC2 Instances (M7i-Flex and M7i) Today we are launching Amazon Elastic Compute Cloud (Amazon EC2) M7i-Flex
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで,10以上のプロジェクト,コードベースを抱える場合にどのようにデプロイの自動化を進めたか,工夫したこと,考慮したことなどをまとめておく. デプロイツールには,Python製のfabricを採用しているが,他のツールでも同様のことはできそう.なお,fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない(最後の参考の項を見てください). fabricの選択 シェルスクリプトとCapistranoを考慮した. まず,シェルスクリプトは人によって書き方が違うため,統一が難しくメンテナンスコストも高い.また共通化も難しい. 次に,Capistranoは,裏でやってくれることが多く,学習コストも高い.プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため,Capistranoの前提から外れる
September 6, 2014Deploy Your Website Using Laravel and Git You can’t be a successful web developer without using some sort of deployment workflow for your websites. It doesn’t matter how good or bad your workflow might be. If you can’t get your website up to production then your client will never pay you for your hard work. There are many different ways to deploy your website to your production se
WebPayではメインのコミュニケーションに2014年2月よりSlackを使っています。 洗練されたインタフェースとエンジニアフレンドリーな機能をもったすばらしいチャットツールですが、いくつか不便な点があります。 そのうちのひとつが検索の性能の悪さです。 英語の文字列でも全然関係ない結果を返してくることが多く、日本語ではほとんど壊滅的になりますっていました(現在はかなり改善されています)。 Slackを利用している日本のチームはいくつもありますが、おそらく同じ問題で悩んでいるのではないでしょうか。 この問題を解決するために、SSlackというツールを作成しました。 (Slack API: Community Built Integrations | Slackにも掲載されました) SlackからOutgoing Webhookで監視しているチャンネル上の発言を取得し、elasticsear
The REST API is now versioned. For more information, see "About API versioning." About deployments Deployments are requests to deploy a specific ref (branch, SHA, tag). GitHub dispatches a deployment event that external services can listen for and act on when new deployments are created. Deployments enable developers and organizations to build loosely coupled tooling around deployments, without ha
ghq をメンテナンスするにあたっていくつか無料の CI サービスを試してみたのですが、今回は Wercker を使うことにしました。いろいろ試行錯誤した結果表題のことがなんとか実現できた(ghq のリリースは GitHub 上 にあります)ので、ハマりポイントと共にこのエントリで紹介します。 Wercker Wercker は CI サービスのひとつで、ビルド環境やデプロイの 1 ステップを box および step という形でユーザが公開・共有し、それらを組み合わせることで CI の設定をシンプルにしようとしているところが特徴です。 ghq の wercker.yml を見てもらえばだいたい雰囲気は分かると思いますが、大まかに言って “box”, “build”, “deploy” の 3 項目をプロジェクトごとに設定します。 box はビルドが走る環境です。OS や、テストに必要なパ
最近話題のCI as a Serviceを導入すべく調査してみました。JenkinsさんもすごくいいのですがAWS smallインスタンスに乗せているとやっぱり本来の力を発揮できない感じがあるので。 CircleCIって以前は、一番安い契約だと1Private Repositoryしか扱えなくて使いづらそうな印象だったのですが、4月末頃にPrivate Repository数は無制限、同時実行ジョブ数で課金というPlanに変更になったようですね。 Simple and Transparent Pricing | The Circle Blog http://blog.circleci.com/simple-and-transparent-pricing/ 自分の関わっているプロジェクトでは、 リポジトリはそれぞれの役割ごとにいくつか分けている 開発者数は少ないのでコミット頻度はそんなに高く
少し前までアプリケーションのデプロイと言えば 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 と連携するこ
今回の問題は、(SA)Strutsだけの問題ではなく、いろんなフレームワークでもちゃんと調べた方が良い話しなので、もう少し詳しく書いておきます。 Javaで、JavaBeansのプロパティにアクセスする場合、 PropertyDescriptor[] descriptors = Introspector.getBeanInfo(クラス).getPropertyDescriptors();で取得できるPropertyDescriptorを使うことがほとんどです。この中に、classプロパティは含まれます。 ここまでは良くて、ネストしたリクエストパラメータ(class.classLoader.xxxなど)をJavaBeansにセットする時に、BeanInfo.getPropertyDescriptors()で取得したものをそのまま使うのが問題なのです。 Seasar2(BeanDesc)では、
JVM Operation Casual Talksで出てた話としてJavaでhot deployってどうしてんの?ってのがありました。 hot deployっていうのはアプリケーションコードを変更してもAPサーバーを再起動せずに反映する技術です。 この辺別に僕は全然知らないし答えを持っているわけではないですが、まあちょっと興味があったのでLL言語でのhot deployとJavaでhot deployを簡単に調べたのでメモっときます。 コードを変更してAPサーバーを再起動する場合、APサーバーが止まっているときにアクセスが行くと困るので、ロードバランサから外してAPサーバーを再起動してまた戻すみたいなことをやるのがオーソドックスな方法のようですが、hot deployだとそういったことをやる必要が無くなります。 Server::Starterから学ぶhot deployの仕組み - $s
https://www.facebook.com/publications/514128035341603/ 1日500件、3,000ファイルに及ぶ本番アップ フロントエンドのコードは1050万行、内850万行がPHP 開発エンジニア1,000名とリリースエンジニア3名 QAやテスターは存在しない 自分でプロジェクトを選ぶ & 自己責任のカルチャーが強い。 1/3のファイルが一人のエンジニア、1/4が二人のエンジニアでメンテされている。 フロントエンドの本番コードベースは一つのものを共有 日常業務ではローカルのgitを利用。本番アップ可能になれば、中央のレポジトリにマージして、それからSubversion(過去の経緯で使っている。)にコミットする 同じエンジニアがコードをコミットする間隔は中央値で10時間 本番にプッシュする前に、担当エンジニア自身でのユニットテストを終え、同僚によるコード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く