AWSのCodeシリーズを利用してサーバーの管理を不要にしたフルマネージドな環境で、DockerコンテナのフルマネージドなオーケストレーションであるAWS Fargateへの継続的デリバリーをどのように実現するかをデモを交えながら解説します。

DevOps ToolchainとしてのGitLabが目指す、これからのDevOpsツールのあるべき姿を紹介します。
GitLabは近年進化を遂げ、バージョン管理システムの機能だけに留まらず、Chatツールを代表とした開発ワークフローから、継続的インテグレーション(CI)、継続的デプロイメント(CD)、フィードバックまでの継続的デリバリを実装できる機能を提供しています。これは、数多く存在するDevOps Toolchainの選定コストを排除し、アプリケーション開発に集中できるプラットフォームを提供するための最善策とも言えます。
本セッションでは、実際にGitLabのCI/CD機能を使ったアプリケーションデプロイメントパイプラインのデモを交えて紹介します。さらに、最新版で強化されたDevSecOpsのセキュリティ機能やKubernetes上で展開するアプリの実装について、GitLabの魅力を最大限お伝えいたします。

過去２回のDevOpsDays Tokyoは、2017年1月末のシアトル訪問から始まりました。
Microsoftを訪問し、いくつかの多様性のある開発現場を見せていただき、英語での闊達な議論もしてきました。

今年のキーノートの Chap Alex さんもそこで出会った一人です。
彼はもともとテストの自動化の役職にいたわけではありません。
スカンクワークスで数年、チームになって３年くらい、今は30人のチームになったといっていました。

別のチームの人は、TFSというプロダクトを作っていましたが、
「ほら社内でこんなに使われるようになったんだよ」
と言っていました。計画経済のようにトップを説得して全体に使わせるなんてことはやっていませんでした。

さらに、そのチームは部屋を工夫し、チーム全員が一部屋に集まり、それでいてほかのチームとは共有しない部屋を作っていました。徐々にほかのプロダクトに広がっていると言っていました。

日本人エンジニアの河野通宗さんが言っていました。
「上司もエンジニアなので意思決定が速いです」
意思決定が速いと何がうれしいのですか？
「クラウドは常にどこかが壊れている。なのですぐに検知して直さなきゃいけない」

世の中がガラリと変わってしまう音が聞こえました。

もう開発者もデザイナーもマネジメントも経営陣も関係なく、リアルタイムに動き続ける世界を相手にして動かないといけない。途中の誰かがわからないから通訳してくれといえば、そこでリアルタイムから弾き出される。

テスト自動化だけ、チームビルディングだけ、上手なデリバリーだけ、得意ななにかをひたすら追いかけて、エンジニアのキャリアパスだけ考えて、残りはほかの人のせいにしておけばよい時代は終わってしまった。全体としていい仕組みを作った企業が生き残る。誰も安住できないグローバル競争をしたたかに生き残って時価総額を伸ばし続けるエンタープライズがシアトルに一つありました。競争している企業もいくつもあります。

私たちの DevOpsDays Tokyo そこから始まりました。

それから一年ちょっとがたちました。

世の中の何が変わったのか、そして、心境はどう変わったのか、ここからどうなっていくのか。

話し合ってみたいと思います。

上長に「お前は技術もマネジメントもビジネスも何も分からないクズ」と言われ、本当に自分が「技術もマネジメントもビジネスも何も分からないクズ」なのかどうかを確認しようと思い立った。

確認する方法としてテスト駆動開発(TDD)でお馴染みの三角測量(その人にはたまたまそう見えたということが起こらないように2つ以上の値を使用してテストをする)で確認することに思い至り、ちょうどタイミングよく運転資金が枯渇し閉店を余儀なくされた馴染みの飲食店とパン屋があったので、そこに自己資金を運転資金として投入し、自分の技術と知識と能力を使って閉店を免れられるのかどうかを確認した結果を紹介する。

DevOps tools and practices have traditionally been Linux-focused, which has presented a significant adoption hurdle in Windows-based organizations. Windows sysadmins rarely need to use a command line to do their job, let alone Ruby, Git, or other tools. Although tool vendors have tried to make “Windows versions” of their Linux tools, and Microsoft has tried adding “Linux features” to the Windows, many organizations still view DevOps as a square peg in a round hole.

To bring DevOps to Windows-based organizations, it’s important to not only understand the cultural differences between Windows and Linux, but learn how you can build a process that truly crosses development and operation silos, and doesn’t just become “the DevOps team”.

This is where "WinOps" comes in. WinOps strives to address the same challenges as DevOps, using different tools with a Windows approach.

アジャイル開発センター発足から1年以上、DevOpsをもっと浸透させるための箱はできました。

実情としては、上手くいっているプロジェクトもあれば、改善が必要なプロジェクトも多々あります。

業務部門、事業部門と兼務した経験から見えてきた、「リリースサイクルを短くするためのDevOps」が浸透しない理由、

そして現在挑戦している対策等を共有したいと思います。

The best way to learn how to succeed is by failing. But when you can’t afford to lose, the next best thing is to learn from other’s people’s mistakes. I’ve seen a lot of DevOps implementation failures over the years, some even due to my own mistakes. In this session, I will review share stories of failure and success, and what I’ve learned is a surefire way to win at DevOps.

GitHubは創業以来、世界中に社員が散らばってリモートワークを行っています。リモートワークをやりながらDevOpsを実現するべく、ChatツールをベースにしたDevOps（ChatOps）を行っているのが我々です。Continuous Deliveryから一歩進んだContinuous DeploymentをChatOpsベースでどのように行っているか、開発フローに沿ってステップバイステップで見ていきます。また、インシデントが発生した時にChatOpsでどのように問題を認識、対応していくのかについてもお見せします。
またトークの中で、巷で（特に日本において）誤解されているGitHub Flowの本当の姿についてもご紹介いたします。

運用の自動化は誰もが目指す理想郷である。しかし現場を見てみると、意外にもその思惑とは裏腹に、導入は進んでいない。特に複雑な運用ほど自動化すれば効果が高いのに、実施されていない。

そこには、ひとえに運用におけるソフトウェア・エンジニアリングの考え方が不足しているのが理由に挙げられる。私達はソフトウェアを作り上げるように、運用を構成しなければならない。これはDevOpsに限らず、近年のSite Reliability Engineering (SRE)の骨子でも同様である。

本セッションでは、運用の自動化を進めるに当たって考慮すべき事項と、その実現手段についてはMicrosoft Azureを用いた一般的なものから、物理ネットワーク運用への適用など特殊なものまで、実例をいくつか交えて解説をする。