usk-abe

[usk-abe]

Spring Cloud Configのリファレンスを読んだメモ

Spring Cloud Config導入の言い出しっぺの手前、やっとリファレンスをまじめに読んだので、まとめでなく、個人的メモ。

さくっと概要を知りたければ、ここが良さそう。

＜Spring Cloud Configのリファレンス読んだ＞

http://kimulla.hatenablog.com/entry/2016/03/04/Spring_Cloud_Config%E3%81%AE%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9%E8%AA%AD%E3%82%93%E3%81%A0

ここからメモ

http://cloud.spring.io/spring-cloud-static/spring-cloud-config/1.2.2.RELEASE/

/{label}/{application}-{profile}.properties "label" is an optional git label (defaults to "master".)

環境=(local,dev,stg,prod)として、各環境のClientアプリは、各環境のConfigServerを参照することになるんだろうな。

プロジェクトごとにブランチ（バージョン）を作成してもらい、labelを使えば、複数のプロジェクトが走ったとしても、特定の環境、DEVとかで異なる設定を同時に使うことができそう。

例を書きたいが一旦省略。

application.properties

server.port: 8888 spring.cloud.config.server.git.uri: file://${user.home}/config-repo

上記は、ローカルにあるファイルを参照していることになるのかな？？

file: prefix it should work from a local repository so you can get started quickly and easily without a server

gitは使うが、ローカルにcloneして使うので即反映できると言うこと？

gitの共有アカウントがあるので、それ使っても良いかも。

releaseブランチまたはmasterにマージしたタイミングで本番リリースになれば、リリース作業が減るのでgitを使うのが良さそう。

もちろんマージ＝リリースになるのでマネージャ承認フローも変えないと。やっぱしまずはファイルで始めて、あとでgitに繋ぐのか良いかも。

Vault

暗号化プリシーを確認するのと、もうチョイ仕組みの理解が必要。あとで読む。

With file-based (i.e. git, svn and native) repositories, resources with file names in application* are shared between all client applications (so application.properties, application.yml, application-*.properties etc.). You can use resources with these file names to configure global defaults and have them overridesdden by application-specific files as necessary.

これイイね。アプリごと個別の設定と全アプリ共通の設定を実現できそう。

Note that in YAML you don’t need to escape the backslash itself, but in properties files you do, when you configure the overrides on the server.

変にハマるくらいなら、propertiesよりYAMLにしたほうが良さそう。

spring.cloud.config.overrideNone=true (default is false)

上書きで良いと思う。

Health Indicator

ちょっとよくわからなかったので、あとでググる。 でも、gitサーバが落ちていたことを考えて、ConfigServerまたはClientでキャッシュしておいてもらえるとうれしいな。要検証。

Encryption and Decryption

JVMにJCEインストール必要があるのか。このセクションはあとでちゃんと読も。

f you want to read the configuration for an application directly from the backend repository (instead of from the config server) that’s basically an embedded config server with no endpoints.

Config Server立てるでよいはず。MQやバッチのアプリがあるし。

Spring Cloud Config Client

全Clientを/refreshしたくないので、Push通知を使うのにSpring Cloud Bus、spring-cloud-config-monitorが必要になるのか。Spring Cloud Busはあとで調べたい。

spring.cloud.config.failFast=true

今のところこれは必要だね

spring-retry and spring-boot-starter-aop retry 6 times　interval of 1000ms

忘れそうなのでメモ。

Health Indicator health.config.enabled=false

あとでググる。

Benefitまとめ

アプリごとの定義ファイルを別けたうえで、設定をConfigServerに集約できるので、

共通の変更を1箇所で管理できる。

設定だけのためにアプリをビルドしなくて良い。

ローカル環境の設定は、一度セットしてしまえば、どのアプリ、どのバージョンでも適用できる。チェックアウトするたびにpom.xmlを書き換える必要はなくなる。

将来的には、masterへのマージやreleaseブランチのコミットで、即時サーバに反映されるような仕組みが作れる。FeatureFlagとかにも使えるのかな？

[usk-abe]

スクラムプロダクトオーナー勉強会に参加してきました（Moving Motivators）

社内の勉強会は参加したことあったのですが、Agile2012に参加して以来meetupに目覚め、場所は社内でしたが（笑）初めて社外的な勉強会に参加してきました。

今回はスクラムプロダクトーオーナー勉強会によるAgile2012で紹介されていた「Moving Motivators」のワークショップでした。

詳しい話は、作者のJurgen AppeloさんのサイトやAgile2012のワークショップ・レポートを書かれている@daipresentsさんのサイトなど参考にしてみてください。

ここでは実際に自分（のチーム）が行ったことを書いています。

STEP 1

まずは「モチベーションとは」を自分で考え、その後に4人のチームでモチベーションを定義しました。「志向性」としました。

STEP 2

架空の「会社名」「事業内容」「会社の転機」を考えます。ここはチームで行います。

Motivation Zero Inc.は応援団やチアリーダーを派遣し、

いろんな会社を応援・元気付けるための会社で、

転機はCMO(Chief Motiavtion Officer）にある人物を採用したことで

燃え尽きた

と設定しました。

STEP 3

続いて配られたカードの説明を受け、右から重要度が高い順に並べます。個人ワークです。

この時ペルソナを使って、実際に自分がその会社で何をしているのかを設定するとやりやすかったです。

STEP 4

会社に転機が訪れ、私のモチベーションに変化がありました。各カードをアゲ・サゲします。

ちなみに、下の付箋3枚がペルソナ。これも個々ワーク。

STEP 5

「モチベーションとは」をチームで再確認です。

個人的には、当初なにか譲れない大切なものと思っていましたが、モチベーションは人により異なり、そのコアとなるものは変化する、と気づきました。

これを会社に持ち帰ってどうやろうかってところは悩み中ですが、動機付けに役立てるのであれば、近いうちに試してみようかと思いました。

いろんな方の意見や発想を聞ける勉強会でしたので、普段の仕事とは違ってとても楽しかったです。