PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
Next.jsアプリケーションを動かす環境をaws-cdkを使って構築する(with CloudFront/S3/Fargate) - $shibayu36->blog;
Next.jsをproduction環境で使うために外観を掴んでおきたいと思い、Next.jsアプリケーションを動かすAWS環境をaws-cdkを使って構築するサンプルを作ってみた。だいぶ荒削りだけど、参考になる例にはなったと思う。 https://github.com/shibayu36/nextjs-on-ecs 利用した技術 AWS CloudFront S3 ECR ECS aws-cdk Docker Next.js + TypeScript 今回作ったアーキテクチャ 全てのリクエストをCloudFrontに通すフルCDNアーキテクチャ フルCDNアーキテクチャ実験 / Minami Aoyama Night #1 - Speaker Deck フルCDNアーキテクチャでサービス設計した話 - Speaker Deck next buildで生成した静的ファイルはS3から配信
PostgreSQLでauto_explainを使ってどのクエリが遅いか把握する - $shibayu36->blog;
ある機能が重いなどといった理由で、DBのどのクエリが遅いか把握したいことはよくあります。そんな時、PostgreSQLのauto_explainが便利だったので紹介。 auto_explainを使うと、指定した実行時間以上を利用しているクエリに対して、自動で実行計画をログファイルに出力してくれるというもの。詳細はこちら。 https://www.postgresql.jp/document/9.6/html/auto-explain.html https://www.postgresql.jp/document/9.6/html/using-explain.html 最近便利に使えたのは以下の設定。 # 自動でEXPLAIN ANALYZEしてパフォーマンス解析したい時用 session_preload_libraries = 'auto_explain' auto_explain.log
goreleaserを使ってGoで書いたツールのバイナリをGithub Releasesで配布する - $shibayu36->blog;
Goで書いたツールのバイナリ配布ってどうやれば良いのかなーと思っていたら、goreleaser というツールを見つけたので使ってみた。非常に便利だったのでメモしておく。 goreleaserとは 簡単に言うと、Goのバイナリのクロスコンパイルと、Github Releasesへのデプロイをやってくれる君。詳しくは https://goreleaser.com/ と https://github.com/goreleaser/goreleaser を参照。 goreleaserのインストール https://github.com/goreleaser/goreleaser/releases からバイナリを取ってくるでも良いけど、僕はgo getでインストールした。 $ go get github.com/goreleaser/goreleaser goreleaserの設定を行う まずはリリ
手元開発環境でサーバを起動時のみcronのようにスクリプトを実行する(Perlの場合) - $shibayu36->blog;
これまでPerlを利用した手元開発環境でどのようにcronを動かすか迷ってきたのだけど、その解決策が見つかったのでメモ。 課題 開発サーバや本番サーバではcronで定期的にスクリプトが実行されている 定期的に実行されているスクリプトが動かないと、正しく動かない機能がある 例えば予約投稿みたいな機能など しかし手元開発環境ではcronのように定期的にスクリプトを実行していなかった 結果として、手元開発環境で手動でスクリプトを動かさないと確認できない機能があった 解決策として手元でもcrontabを書く方法もあるのだけど、この場合開発していない時も勝手に実行されるので避けたかった。 解決方法 実はProclet というツールに、サーバを起動しながら定期的に指定したコードを実行してくれる機能があるということに気づいた。詳しくはSYNOPSISを参照。 これを使ってcronに指定しているスクリプト
知識ゼロからElasticsearchを実践で使えるようになろう！ - $shibayu36->blog;
以前少しだけElasticsearchを触った時に、自分流Elasticsearch入門 - $shibayu36->blog; というElasticsearchに入門した時のメモをまとめていた。しかし、その頃はElasticsearchを使って完全に一人で一つの機能を作るというところまではいけなかった。 最近になってまたElasticsearchを一から導入する仕事をすることになった。この時以前自分がまとめた記事を読みながらやっていたのだが、実践で一から導入するためにはこの記事だけでは知識が足りなかった。 そこで、前の記事の知識をベースに、一から導入するために少しずつ学んでいき、自分のブログにまとめるなどのことをしてきたので、今回はその締めくくりとして、知識ゼロからElasticsearchを使えるようになるために学習したことについて書いておきたいと思う。 今回書くこと・書かないこと 今
WEB+DB PRESS vol.94で「Perl開発への動的な型制約の導入」について執筆しました - $shibayu36->blog;
WEB+DB PRESSのPerl Hackers Hubで執筆しませんかとお声がけいただいたので、「Perl開発への動的な型制約の導入」について執筆しました。本日発売です。 WEB+DB PRESS Vol.94 作者:藤原 俊一郎,朽木 拓,八木 俊広,吉田 太一郎,うらがみ,のざき ひろふみ,うさみ けんた,水嶋 淳貴,佐々木 健一,柴崎 優季,前島 真一,伊藤 直也,遠藤 雅伸,ひげぽん,海野 弘成,はまちや2,竹原技術評論社Amazon 今回は、動的な型制約とは何かや、なぜPerlに導入したいのか、Smart::Argsを使った型制約の導入方法、型制約の応用など、動的な型制約にまつわる内容について書きました。Perlでもっと安全に開発したいと思っている方には参考になると思うので、是非見ていただければと思います。見出しは次のとおりです。 なぜ動的な型制約を導入したいのか Smart
git gcの自動実行はいつ行われるのか - $shibayu36->blog;
gitを使ってるとたまにgit gcが走る。これがどういうタイミングで実行されているか調べたので軽くメモしておく。 Gitでは時々auto gcが走る Git - Book を見ると、以下のように書かれている。 Git は時々 "auto gc" と呼ばれるコマンドを自動的に実行します。大抵の場合、このコマンドは何もしません。もし沢山の緩いオブジェクト（パックファイルの中にないオブジェクト）があったり、あまりに多くのパックファイルがあると、Git は完全な（full-fledged）git gc コマンドを開始します。 さらに、auto gcは普段は何もせず、特定の条件を満たすと実際にgcするとも書かれている。 繰り返しますが、これは通常は何も行いません。約 7,000個もの緩いオブジェクトがあるか、または50以上のパックファイルがないと、Gitは実際に gc コマンドを開始しません。これ
社内Cartonコードリーディング会第一回のメモ - $shibayu36->blog;
最近社内でCartonを使う機会が増えてきているのですが、そもそもCarton自体が何やってるかちゃんと把握できてなくてハマったりするので、社内有志でコードリーディング会を開催しています。今回は第一回のときに出てきに作ったメモを公開します。そのままメモを公開しただけなのでかなり雑です。間違ってることも多いと思います。 今回の目的 carton install周りで何が起こっているかざっと把握する 疑問とか snapshotが環境によってずれることがあるけどどうして？ --deployment, --cachedとかがついた時に何が変わるか cachedしてもcpanにfallbackしてたけどなぜ インストール先の切替はどうするのか そもそもversion固定どうやってるか 順序は関係なくversionが固定されるのか cpanfileはperlスクリプトとして認識されるのか local以
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
serfとDockerでクラスタを組んでみる - $shibayu36->blog;
最近Serfというツールも気になっていたので、とりあえずクラスタを組んでイベントハンドラの設定をしてみるところまでやってみました。 Serfとは http://www.serfdom.io/ https://github.com/hashicorp/serf Serf is a decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant. Orchestrationという層を支援する軽いツールみたいですね。これをうまく使うことで、クラスタにjoinしたweb serverを自動的に配下に加えるHAProxyとかを実装したり出来ます。参考: Serf+HAProxyで作るAutomatic Load Balanc
Immutable Infrastructureに対する自分なりの考えメモ - $shibayu36->blog;
インフラ系技術の流れ - Gosuke Miyashita 今さら聞けない Immutable Infrastructure - 昼メシ物語 2014年のウェブシステムアーキテクチャ - stanaka's blog http://rebuild.fm/25/ この辺りを読んだ。自分の中ではImmutable Infrastructureについてはここ一週間で調べただけであり、解説などは出来ないが、とりあえず自分用のメモとして自分の思ったことなどを書いていく。 コンテナベースのデプロイ Dockerなどが出てきたことにより、Dockerのイメージをそのままアップロードし、それを本番でも動かすということが出来そうというのが面白かった*1。こういう風なフローになるとすると、これまでのデプロイ手順とは全く違うようになりそう。 これまでのデプロイと、コンテナベースのデプロイ これまでのデプロイは
Dockerで立てたコンテナにsshで接続する - $shibayu36->blog;
最近Dockerをちょっと触っていて、とりあえずDockerでコンテナを立ててsshでつなぐということをやってみた。 Dockerを入れる macだとDockerが入っているvagrant環境があるのでそれを落としてくる。 http://docs.docker.io/en/latest/installation/vagrant/ $ git clone https://github.com/dotcloud/docker.git $ cd docker $ vagrant upこれでDockerが動くvagrant環境が出来た。今後の作業はこのvagrantにsshした状態で行う。 $ vagrant ssh sshdが起動したコンテナにつなぐ http://docs.docker.io/en/latest/examples/running_ssh_service/ この辺を参考に。 まず
carton化を進めています - $shibayu36->blog;
OrePAN的なやり方でモジュール管理していたプロジェクトのcarton化を進めているので、進捗をメモしてみる。 整合性が取れるまでcarton installを進める 現状のモジュールのバージョンを完全に固定したままで、carton installしたらあまりうまく行かなかった。プロジェクトにはテストがかなりあるので、まあ全部バージョン上がっても良いとして、carton installする。テストを走らせてみて、バージョンを固定しないと動かないようなモジュールはcpanfileに記述していった。 $ carton install $ # なんかおかしかったらcpanfileを編集 $ carton install cpanfileには以下の様な形でモジュールを固定していった。 requires 'HTTP::Message' => '<= 6.02'; またinstallが終わった後はc
AWS, chef, Cinnamon等を使った無停止デプロイ(PrePAN carton 1.0化の裏側) - $shibayu36->blog;
最近PrePAN uses carton 1.0 now! - $shibayu36->blog;でも書いたとおり、PrePANのcarton 1.0化を進めていました。 通常であれば変更点をアプリケーションサーバにデプロイし、サーバを再起動すれば良いのですが、cartonを0.9から1.0に上げるというまあまあ大きな変更を加えるため、事前に動作確認を行い、無停止でデプロイしたいと考えました。そこでAWSを使って無停止デプロイを試してみたのでそれについて書こうと思います。 PrePANのサーバ構成やデプロイ手順の検討 無停止デプロイの説明の前にPrePANのサーバ構成を紹介しておきます。 現状はELB 1つに対し、EC2が2台ぶら下がっているという状態で運用しています。そしてEC2に対してはそれぞれapp-1, app-2という名前でタグがついています。 開発メモ#2 : AWS でのホス
いろいろなツールをplenvに移行した - $shibayu36->blog;
最近はplenvを使うべきって感じだったんだけど、promptとかemacsとかを対応させるのがちょっと面倒でサボっていた。そろそろやばいと思ったので全部plenvに移行した。 インストール macだったらbrewで提供されているので入れる。https://github.com/tokuhirom/plenv を参考に。 $ brew update $ brew install plenv $ brew install perl-build $ plenv install 5.14.2 # お好みのperl入れる $ plenv shell 5.14.2 $ plenv install-cpanm promptに現在利用しているperlのversionを出力する 以下のように、promptにperlのversion出てるとうれしいのでそういう感じにする。 plenv version-nam
Test::Moreのsubtestで困っていること - $shibayu36->blog;
最近はperlでテスト書く時はTest::Classを使うようにしている。その理由の一つとして、subtestだけのテストだと少しだけ困ることがあるからだ。 具体的には以下の事がある。 subtestは書かれている順に実行されるため、前のテストの状態に依存したコードが書かれがち 特定のsubtestだけを実行するのが面倒 前のテストの状態に依存したコードが書かれがち 僕の中では、テストが前のテストの状態に依存しないようにすべきと思っている。各テストの依存度が増えると、その後テストを追加したいときにコードの見る範囲が増え、テストが書きづらくなってしまうからだ。 しかし、subtestは単に書かれた順にテストが実行されるので、前のテストの状態に依存したコードが書きやすいと思っている。例えば以下の様なコードが書かれがち(少し極端な例だが)。 use Test::More; # insert_en
処理のtimeoutを簡単に書くためのSub::Timeoutというモジュールを作りました - $shibayu36->blog;
ある処理をするときに一定以上の時間かかったらtimeoutして処理を終わりたいみたいなことをしたい時がたまにあるので、それを行うSub::Timeoutというモジュールを作りました。 https://github.com/shibayu36/p5-Sub-Timeout 使い方 use Sub::Timeout; use HTTP::Tiny; my $res = timeout 3.5, sub { HTTP::Tiny->new->get('http://example.com/foo'); }; 基本的には上のように、タイムアウトしたい秒数と処理のcoderefを渡します。 上の例だと3.5秒間で処理が終わった場合、その返り値を$resとして返し、処理が終わらなかった場合、その時点で処理を打ち切って例外を投げるようにしています。例外を投げるのでその後も処理を続けたい場合は例外処理をし
Cinnamonにmax_concurrency設定をつけました - $shibayu36->blog;
並列化に伴い、タスクごとの最大並列数を設定できるようにしました。 以下のように設定すると、updateは全hosts並列で動き、restartは1並列、server:setupは最大2並列で動くようになります。 use Cinnamon::DSL; set max_concurrency => { restart => 1, 'server:setup' => 2, }; role production => sub { my $res = LWP::UserAgent->get('http://servers.example.com/api/hosts'); my $hosts = decode_json $res->content; $hosts; }, { branch => "master", }; task update => sub { my ($host, @args) =
Kansai.pmに行ってCinnamonというデプロイツールについて発表しました - $shibayu36->blog;
http://www.zusaar.com/event/476003 に参加して来て、前作ったデプロイツールであるCinnamonについて発表して来ました。 発表したこと 以前capistranoの奥深さに毎回ハマっているのを怒りを覚えて、もっとシンプルなデプロイツールであるCinnamonをantipopさんと一緒に作ったのでその発表をしてきました。それなりに好印象っぽかったので、発表してよかったです。 スライド Cinnamon - simple deploy tool from Yuki Shibazaki デモで使ったサンプルコード https://github.com/shibayu36/cinnamon-deploy-sample 簡単に紹介すると CinnamonはMinimumというのと、Role x Taskというのを思想として持っている Minimum : デプロイの方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
