DevOpsDays Tokyo 2019行ってきたよー Day1
Summary
DevOpsってよく聞いてたけど、よくわからんかったけど、いろんな人の話を聞いてDevOpsってサービスを開発して運用するための新しい働き方、組織のあり方、文化を作ること、なんだなあと思いました。 そのためには開発だけではなく事業部や編成などステークホルダーを巻き込んで文化を変えていくパラダイムシフトが必要そうだと言うことがわかりました。
講演
Lessons Learned Since The Phoenix Project
How do you migrate over 75,000 of the most demanding software engineers from infrastructure built up over decades of high-intensity work into a common engineering system based on modern software development technologies and best practices? This is exactly the challenge faced by Microsoft as they moved to their One Engineering system, a globally distributed 24x7x365 service hosted in Azure DevOps. Edward Thomson will explain how we did it, the lessons that we learned along the way, and some of the technical challenges that still remain.
The DevOps逆転だ！ 究極の継続的デリバリー[ 原題: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ] という著名な本があることを始めて知り、その著者の方の講演でした。ITオフィスでの運用における問題に対する対処、改善、組織改革を小説として書いた本のようです。読んでみようかと興味はあるのですが、結構分量があり、パラパラとめくると読み進めるの大変そうだなーと^^;
楽天ブックス: The DevOps逆転だ！ - 究極の継続的デリバリー - ジーン・キム - 9784822285357 : 本
—
Service Operation Centered Development - サービス運用をまんなかにおいた開発
サービス運用をまんなかにおいた開発についてお話します。
僕は2010年から楽天の大阪支社でウェブアプリケーションエンジニアとして仕事をしています。僕のいる部署は中規模から小規模のたくさんのサービスを担当していて、1つのチームまたはグループでサービスの開発と運用の両方を担当しています。
サービスの開発と運用の両方を担当しているため、僕らはサービスの運用のことを常に考えながら開発に取り組んでいます。運用のことを考えずに開発をすると全てが自分たちに跳ね返ってくるからです。 このセッションでは、サービスの運用をまんなかに置いて開発をするときに、どのようなことを考えるか、また、どのように他のチームや組織と向き合うか、について自分の経験を元にお話したいと思います。
Service Operation Centered Development - Speaker Deck
こういうチームで働きたいよね。
問題があるときは個人に問題を求めるのではなく場に問題があると考えたいです。
カーブの先を見るというのも、先を見越して勉強するとか、今後くる流れを見据えておくとワタワタしなくなって良さそうです。人生においてもカーブの先を見通しておきたいですね。
—
Behavioral Driven Development in DevOps: beyond the development!
In DevOps world is always a challenge monitoring the websites and application business and features health when it gets to the production environment. Testing and granting everything is working as expected, after deployed to production, is tough, and sometimes looks impossible.
During the website/web application development, we usually apply some techniques to achieve that: TDD and Automated Tests, BDD using a gherkin family tool and so on. It is often focused on Development itself and the automation usually finalizes on the last build to production.
BDDを行う上でシナリオを記述するのにガーキン言語というのを使おうと言う話がありました。
Given(前提), When(条件), Then(ならば), And(かつ), Or(または)などを使って自然言語で書こうという方針のようです。Gherkin Reference : Cucumber.
サービスがでかすぎて全部をテストしようとするとテスト兵士が必要なほどタイヘン！そんなリソースは現実的に用意できないし工期も伸びてしまう。だから必要十分なE2Eの自動テストを導入しよう！ということですね。
BDDな自動テストを書くことで、フロントから見た仕様がわかりやすくなる、自動テストが回る。という点でBDDは魅力的に思えます。今の開発にどうしたら導入できるか考えていきたいです。
