はじめに

上記の書籍でモダンな開発手法についてまとめた備忘録です。メモ程度に、、、
ユーザ(運用側)が求めているシステムを考慮しつつ、開発効率をあげるみたいな観点で調査したつもりです。。

書籍以外の参考
https://licensecounter.jp/azure/blog/topics/20180223.html

開発の問題点

• 開発プロセスを重視して、運用の仕事が切り離される。開発以外のチームに特定の手法を強制する。
• DevOpsは開発（Development）と運用（Operations）の頭文字を取った言葉で、開発担当者と運用担当者が密接に連携し、要求に対して迅速かつ柔軟に対応できる仕組み作りをしようという考え方。
• 開発チームと運用チームの衝突は珍しいことではなく、最近のシステム開発では小さな開発サイクルを繰り返すことが多いため、開発チームは常に改善や修正を繰り返すことに目が向く。一方、運用チームにとっての最優先課題はシステムの安定稼働なので、システムに致命的な問題さえなければ手を入れたくないと運用チームが考えるのはごく自然なこと。その結果、相反する考えを持つ両者は衝突にいたるというわけで、これは現在のシステム開発の現場にとって、大きな損失となる。
• そこで、開発チームと運用チームの両者が開発に関わることで衝突を避け、新たなシステムの要求から実装に至るまでの時間を短くすることがDevOpsが目指すもの。

ソフトウェア開発のこれまで

• water fall ウォーターフォール
  - 要件定義
  - 概要設計
  - 詳細設計
  - 開発
  - テスト
  - 運用
  といった各工程にわけて直線的に結合し、前の工程のドキュメント作成などを完了してから次の工程に入る、といったスタイルで運用していきます。原則的に手前の工程で決めたことを尊重して、戻り作業を発生させないという考え方です。

  • ハードウェア工学で採用されていた（製造業、建築業で生まれた）。1980にソフトウェアに取り入れた
  • 元々ソフトウェアはCDROMで流通してたので、修正して再配布するのはコストがかかるから、はじめからしっかり要件を定義して作る必要があった。

• Agile アジャイル

  • 2001のアジャイルマニュフェストで原則ができた
  • 機能ごとに計画からテストまで行う「イテレーション」というサイクルを繰り返しながら、全体の開発を進めていく。ウォーターフォールに比べて、仕様で決めた実物をいち早く確認することもできる。
  • 人、対話、コラボレーション(開発側と運用側の協力)を強調している。これはDevOpsとも共通

• スクラム

  • アジャイルの一種
  • スプリントと呼ばれる。1- 4週間のサイクルを繰り返す。
    • スプリントランニング:目標設定
    • スプリントレビュー:達成した成果を確認
    • スプリントレトロスペクティ:スプリント中の問題点を議論
  • デイリースクラム:立ったまま行うミーティング。メンバーは3つの質問に答える。
    • チームが、スプリントの目標を達成するために、昨日何をしたか
    • チームが、スプリントの目標を達成するために、今日何をするか
    • 目標達成の妨げとなるものは何か
  • チームリーダーはスクラムマスターと言われる

• DevOps

  • 開発チームと運用チームの両者が開発に関わることで衝突を避け、新たなシステムの要求から実装に至るまでの時間を短くすることがDevOpsが目指すもの。
  • DevOpsでは具体的な開発手法より情報の共有ツールやテストツール、自動化の仕組みなどがフォーカスされやすい。それらの個々のツールが大切なのはもちろんだが、最終的にはビジネスのスピードアップに対応できる組織と仕組みを作る、ボトルネックを把握するというところを意識することが肝心。

運用手法例

運用側が気にすることのの事例集みたいな、成功事例のようなもの

• ITIL information technology infrastructure library
  • itサービス管理のためのプラクティス集。
    • プロセス
    • 手順
    • タスク　
    • チェックリスト 　　　　　　　　上記などをまとめた。1980くらいit組織が増えたからできた。
  • 最新版は2011で。サービス戦略、サービス設計、サービスの変遷、サービスの運営、継続的なサービスをコアセクションにしてる。資格とかもある
• COBIT control objective for information and related technology
  • ISACA（情報システムコントロール協会）が1996にリリースした情報と技術のgovernance（統治のあらゆるプロセスを言う）と管理のフレームワーク。
  • 5つの原則がある
    • ステークホルダーのニーズに応える　利害関係者
    • 企業全体をカバーする
    • ひとつに統合されたフレームワークを適用する
    • 包括的なアプローチを実現する
    • ガバナンスとマネジメントを分離する

開発、リリース、デプロイの諸概念

開発を効率化するための考え方

• バージョン管理

  • バージョン管理を表す英語⇨SCM(software control management) , revision control , version control , source control ,,etc
  • ひとつまたは複数ファイルに対する変更を記録するのに使う
  • 対象は、ソースコード、asset（資材、ソフトウェア、ライセンスなど）、ドキュメント、など。
  • 一度に行った変更の集合をコミット、revison（修正したときの版数）という。
  • バージョン管理システムを使うと、本番環境のオブジェクトを前のバージョンに戻せるのでリスクは最小になる。

• TDD test driven development　テスト駆動開発

  • 開発者はまず新しいコードのために失敗するテストを作る。その後にコード自体をかいて、最後にコードが完成したらテストする。テストを先に書くと、新しい機能を明確に定義できるし、コードが行うべきことがはっきりする。
  • 開発者自身がテストを書くことで、フィードバックループが大幅に短縮される。また開発者が自分の書いたコードに責任をもつようになる。責任の共有と開発サイクルの時短ができる。これはDevOpsと共通する。

• デプロイ

  • デプロイとはソフトウェアリリースの計画作り、リリース実行、保守を含むプロセスを指す。
  • システムの依存部分を自動で構築すると、依存部分の不一致が与える影響を最小化できる。（Chef:インフラストラクチャー自動化）
  • データベースのデプロイでは厳格な整合性保証が必要になる。
  • アプリケーションのデプロイは、高品質なソフトウェアの実現に極めて重要。

• CI continuous integration 継続的統合

  • 開発者が書いたコードとマスターブランチを頻繁に統合するプロセス
  • CIシステムは統合の成功を確認するため、新しい変更のたびにテストを自動実行する。
  • テスト結果は可視化される、緑はok 赤はビルドに問題あり

• CD continunous delivery　継続的デリバリー

  • ソフトウェア工学の一般的な原則を集めたもの
  • 自動テストとCIを活用して、新しいソフトウェアを頻繁にリリースできるようにする。
  • 新たな変更をしても自動テストが失敗しないようにするだけでなく、変更をデプロイ可能にすることがCDだとされてる。

• CD continunous deploy 継続的デプロイ

  • 変更を本番環境にデプロイするプロセスのこと。
  • 継続的デリバリーではデプロイ可能にするまでだったけど、本番環境に実際にデプロイするのが、継続的デプロイ。
  • デプロイが早くなるので、顧客満足度、開発者の達成感も向上する

• 継続的デリバリーと継続的デプロイについて

  • デプロイはウェブアプリケーション特有だが、デリバリーはIotや組み込みソフトウェアを含む、あらゆるソフトウェア開発プロジェクトに応用可能な一般的な原則の集合を指す。

• CM configration manegiment 構成管理

  • システムのライフサイクルをインフラ、フロント、エンドまで一貫性を維持するプロセス。
  • Chef バージョン管理 provisioning（インフラのスケーリングを考慮して予備を持っておくこと？）とは区別されないで使われる。

• クラウド　cloud computing

  • インターネット経由の共有型のコンピューティングのこと

• Chef

  • システムを構築する方法の一つ
  • 自動化により作業時間を軽減（例　会社の全てのサーバにコマンドを手作業で実行するのでなく、1ステップで実行できるシェルスクリプトにそれらのコマンドをまとめるのが自動化）