GitOps とデプロイ - Mitsuyuki.Shiiba
昨日はトランクベース開発とデプロイについて書いたので bufferings.hatenablog.com この勢いで GitOps とデプロイも書いてしまうー。先に言っておくと、自分は GitOps の経験はない。でも、よさそうだなぁと思う手法なので、機会があれば挑戦してみたい気持ち GitOps? GitOps は2017年に Weaveworks の Alexis によって提唱された手法で、Kubernetes を対象としている Guide To GitOps Git のリポジトリーに入れてある設定ファイルを Single Source of Truth として、Kubernetes のクラスター管理とアプリケーションデリバリーを行う。上記の記事には次の4つの原則が書かれている システム全体が宣言的に記述されていること 正規の望ましいシステムの状態が Git でバージョン管理されている
最近 Fitbit つけて散歩してるので CircleCI + Pixela で見えるようにしてみた - Mitsuyuki.Shiiba
歩数で草を生やしてみたのだー。これで散歩の楽しみが増えたなー やってること やってることはシンプルで、こう↓ Fitbit の API で歩数を取得 Pixela に記録 というスクリプトをつくって CircleCI で定期的に実行 Fitbit? 最近 Fitbit Sense というスマートウォッチをつけて散歩してる www.fitbit.com 会社の福利厚生で健康のための補助があるので、それを利用して手に入れたのだ。散歩やジョギングをしたら勝手に記録されてるので便利。睡眠のログも取られてるので面白い Pixela? Pixela は日々の活動を記録して見えるようにしてくれる API サービス。いちばん最初に貼った画像みたいに GitHub の草を生やすやつみたいにしてくれる。操作が全部 API 経由なのも楽しい pixe.la せっかく散歩してるから せっかく散歩してるから Fit
Java 8でも安心。Dockerに対するCPU・メモリ対応。（2018年11月現在） - Mitsuyuki.Shiiba
8u191でDocker対応がバックポートされたので、頭の整理と確認をしておいた。 ## まとめ Java 11使っておけばそもそも安心なんだけど、Java 8でも8u191以降を使えば安心。 ## 課題だったこと DockerでJavaを動かすときJavaが「そのコンテナに割り当てられたCPU・メモリ」じゃなくて「Dockerが動いてるHostのCPU・メモリ」を見てしまうことが課題だった。 ## Java 10以降 Java 10以降なら「そのコンテナに割り当てられたCPU・メモリ」を見る対応が入ってるから安心になった。 https://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html#JDK-8146115 ## Java 8は？ Java 8で入ってた対応は8u131のこれ： Bug ID:
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
Prometheusを触ってみる。のをDockerでやってみる。のとgrafana。 - Mitsuyuki.Shiiba
昨日の朝、ぼーっとしてたらこんな記事があったので qiita.com Prometheusっていうモニタリングツールがあるのかぁと思って。 prometheus.io 触ってみようかなと思ったのでした。 まずは動かす Dockerで動くとあんまり何も考えなくていいなぁって思ってたら、ちゃんとあった( Installing | Prometheus )。(∩´∀｀)∩ﾜｰｲ docker run -p 9090:9090 prom/prometheus で、9090にアクセスしたらとりあえず動いてる。 自分自身を監視してみる さっきのは起動しただけで何も情報がないので、実際に監視してみるとどんな感じになるのか。サンプルとして自分自身を監視できるみたいなのでやってみよう。 Getting started を読みながらprometheus.ymlってファイルを作って global: scrape
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
