DevOps入門2

外資系企業のソフトウェアエンジニアをしております、タロイモと言います。

前回の記事ではDevOpsの概要について書きました。

今回も技術トレンドであるDevOpsについて解説していきます。今回は、前回のDevOpsの概要を踏まえて、具体的にどういうツールを導入すれば良いのかについて説明していきます。

<この記事のゴール>
・読んでくれた方がDevOpsに取り組む上で、どのようなツールや文化を組織に導入していけば良いのか理解できるようになる。

<この記事の対象者>
・インフラ構成やプログラミングなどの基本IT知識を有している人。

1. DevOpsを組織が導入する上で大切な5つのこと

DevOpsを組織が導入する上で、大切なことは抽象的にいうと以下の5つになります。

⑴属人性の排除
⑵インフラ環境構築の抽象化
⑶作業の自動化
⑷情報の共有化
⑸共通の目的意識

一つずつ説明していきます。

⑴属人性の排除
開発者やインフラエンジニア（運用担当者）のどちらにも言えることですが、自分にしか分からないコードを書いたり、システムを構成したりすると、それだけで伝達ミスや認識ミスが生じます。

誰が見ても理解できるコードやシステム構成にすることが大切です。
（鰻屋が作る秘伝のタレのようなコードはやめましょう）

⑵インフラ環境構築の抽象化
開発者から見て、インフラエンジニアの仕事ってかなり複雑に見えますよね。負荷分散、冗長化、、、サーバー構成が書いてあるシェルスクリプトを見てもよく分かりません。

そんな何をやっているか分からない人たちに、「サーバーに負担が掛かるコードの書き方はやめろ」、「セキュリティが甘い、しっかりしてくれ」なんて言われても不満だけが生まれます。

逆に、インフラエンジニアから見たら、開発者は自分たちの満たす要件に適合しないコードを渡してくる”厄介者”になり得ます。

このようなことを防ぐために、開発者もインフラを理解することが大切です。

⑶作業の自動化
前回の記事でも触れましたが、昨今のビジネス環境では一回で完璧なプロダクトを作るのでなく、市場のフィードバックを繰り返して、良いプロダクトを作り上げていくことが必要です。

しかし、⑵インフラ環境構築の抽象化でも言いましたが、開発者とインフラエンジニアに壁があるとテストやデプロイ（市場に展開）するのにも一苦労です。

そのような、苦労を取り除くことが大切です。

⑷情報の共有化
⑵インフラ環境構築の抽象化で触れましたが、開発者とインフラエンジニアはお互い何をやっているか理解できていないことが多いです。そのため、認識に違いが生まれ、問題が発生することになります。

また、開発者同士でも一緒に開発している人が何をやっているかが見えるとスムーズなコミュニケーションや仕事の分担ができます。

例えば、特定のJavaScriptファイルの何行目について質問したい時に、コードが共有されていないと説明するのが大変です。

情報の共有は、コミュニケーションを円滑に進める上で大切です。

⑸共通の目的意識
前回の記事でも触れましたが、何よりも大切なのはDevOpsに取り組む「人」です。

2. 5つの大事なことを達成するためのツール

次は5つの大事なことを達成するためにどんなツールを使えば良いのか説明していきます。

⑴属人性を排除するには
コーディングでは、開発者はチームのコーディングルールを作りましょう。ルールは逐一改善していくことも重要です。
また、LinterやPrettierなどのコードフォーマットツールを利用することも良いです。

インフラ構成では、Excelなどのドキュメントで管理するのではなく、インフラ構成ツールを利用しましょう。
例えば、RedHatのAnsibleというインフラ構成ツールはYAML形式（コード）で書くことができ、手順が明確に記載されることになるので、開発者もインフラがどのような構築されているのか理解しやすくなります。
→Excel等のドキュメントだと手順形式が人や組織によってバラバラになることが多い。

#AnsibleのYAML形式

- name: apache installed
 yum:
   name: httpd
- name: httpd service started
 service:
   name: httpd

⑵インフラ環境構築を抽象化するには
(1)属人性を排除するにはでも触れましたが、Infrastructure as Code（以下IaC）という考え方が大事です。IaCは「インフラ構成もコードで書く」という手順方法で、開発者もインフラ構成に携わるDevOpsにおいて有効な手法です。例えば、簡単にインフラ環境を構築できるコンテナ管理ソフトウェア"Docker"のDockerfileは指定形式でのみ書くことができ、同様の環境をMac上でもWindows上でもLinux上でも簡単にミスなく作ることができます。
→抽象化とは誰でも理解できるという意味で使用しています。
→逆の具体化とは具体的な人しか利用できないという意味になります。

#Dockerfile形式

FROM centos:7
RUN yum install -y httpd
RUN echo '<h1>Hello World!</h1>' > /var/www/html/index.html

Docker入門（第一回）～Dockerとは何か、何が良いのか～ | さくらのナレッジ

⑶作業を自動化するには
何度も繰り返しますが、開発者とインフラ担当者の壁を取り除くには共通言語が必要です。

アジャイル開発においては、ビルド、テスト、デプロイが頻繁に行われます。継続的インテグレーション(CI)ツールは、そのような作業を自動化し、つなぎ目をなくし、インフラの見える化・開発担当者とインフラ担当者の情報共有の負担軽減に役立ちます。

また、CircleCIなどのCIツールはYAML形式で書かれるためIaCにも当てはまります。

最先端の CI/CD ツール

⑷情報の共有化をするには
情報共有は認識違いをなくす上で大切です。

GitHubなどのソース管理システムやCIツールをSlack等のチャットアプリに連携させることで、進捗状況の見える化に役立ちます。

GitHub: Let’s build from here

チャットアプリなどをCIツールに連携させると、「ビルド」とbotに対し呟くだけで自動ビルドを開始させることも可能です。このような日常生活で使う言葉が使用できることで、コミュニケーションの難しさは一層減るでしょう。

⑸共通の目的意識を作るには
DevOpsをチームに導入するには、かなりの反発があると思います。

「旧来やってきた方法で上手くやれているのだから、新しい考えを導入して失敗したらどうするつもりだ」などと怒られるかもしれません。

変化というものはかなり疲れるものです。

以下の書籍では、DevOpsを既存の組織に導入する方法としては、トップダウンよりもボトムアップによるアプローチを推奨しています。

DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する

会社丸ごと変えるのが無理ならば、部署を変える。
部署を変えるのが無理ならば、チームを変える。
チームを変えるのが無理なら、隣の席の人を変える。

このように身近なところから、徐々に啓蒙していくことがコツです。

3. まとめ

以上でDevOpsを実践する上で利用したいツールの概要説明は終わりです。

具体的なツールの使い方は、今後の記事にて触れていきたいと思っております。