開発の流れ
[アプリケーションを作る時]
「要件(して欲しい事)」があり、それを実現するための作り方や体制、仕組みなどを決める。この時、「要件定義」「アーキテクチャ選定」のような言葉が使われる。上記から作るものが決まり、機能の数や種類がわかった上で、それをどう作るかという具体的なところに向かう。
これをいわば「設計」フェーズという。
●全体設計
規模が大きい場合は色々な人が同時に作る事になる。設計の仕方、作り方を細かく取り決めたりして、全体設計には多大なコストがかかる。
※「なら早く作り始めたほうが良い」となるものの、品質を担保する為には全体設計をした方が良いため、一概に判断するのは難しい。
⇒設計 → 実装 → テスト → 納品、となる。
[意識すべきこと]
・何かが起きた時に、その対処をどうするか、という事を事前に考えておく必要がある。
・問題が起こるのであれば逆に問題を早く起こして、早く対処すればいい、という考え方もある。
・問題を先延ばしにしない。失敗を評価する。
一般的なシステム開発の進め方（プロセスモデル）
●Vモデル（①～⑩の流れ）
①要求分析←→⑩受入テスト
②要件定義←→⑨システムテスト
③基本設計←→⑧結合テスト
④詳細設計←→⑦単体テスト
⑤コーディング←→⑥コードレビュー
●Wモデル
従来のVモデルをさらに進化させた手法。 一言でいうと、「開発（設計）とテストを、プロジェクトの初期段階から並行して進めるモデル」である。
[開発プロセスのフレームワーク]
| ウォーターフォール | 工程を水のように表した方式で、上流から下流へと一方方向に進む。その仕組み上、下流の工程で発見した上流の漏れを戻って含める(上流へ戻る)ということはできまない。 |
| アジャイル | 要求から開発・テストまでの流れを何度も繰り返す。積極的に発注者とやりとりを行うので、成果物のブレは少ないが、全体を一気に開発する、などはウォーターフォールが適している場合もある。 |
| スクラム | アジャイルの手法の 1 つで、アジャイルの流れを周期的に繰り返し、振り返りや評価を含めつつ進める。(プランニング、デイリースクラム、スプリントなど) |
●テスト駆動開発(TestDrivenDevelopment:TDD)
設計に基づいて製品を開発する(プロダクトの開発)ではなく、まずは設計に基づいて製品の仕様を満たす条件を確認するテストを先に作成するという手法。
・品質を高める為にリファクタリングによって振る舞いを変えずにプログラムの整形を行う。これを何度も繰り返す事で納品へと進む。
DevOps
名の通り「開発(Dev)」と「運用(Ops)」を組み合わせた言葉。今まで対立構造になりやすかった開発チームと運用チームのライフサイクルを一緒にし、協力関係にする事でよりビジネス価値を高めやすい開発と運用を行う為の技術や行動の総称を指す。
[対立構造について]
・開発チーム：新機能の追加やパッチによる頻繁な更新を良しとする
・運用チーム：安定的な稼働を求め、安易に新機能の追加や更新を良しとしない
※非常に技術の範囲が広い上、求められる知見も広くなるため、厳密に DevOps はここからここまで、と言いにくいのが現状。
[始め方]
・まず今まで開発、運用と分かれていたチームは統合する。
・開発時には運用考慮をした実装、環境の構築を行う。
・運用時は得られた知見や分析結果をリアルタイムで開発メンバー含めて共有できるようにする。
[日々改善活動]
- 運用面
情報をリアルタイムで共有する為の Slack 活用や、Bot ツールによる運用サポート。
問題発生時のアラート通知、SNS 通知、自動アクション、監視・分析ツールとその支援。 - 開発面
インフラ環境、ビルドやデプロイの各種自動化やダウンタイムをゼロにする仕組みの構築。
運用を安定化する為のシステム設計、レプリケーション機能の構築、冗長化構成の実現、自動バックアップや復旧の自動化。
CI/CD ツール
「Continuous Integration/Continuous Delivery」の略称では「継続的インテグレーション」「継続的デリバリー」ともいう。
●CI(継続的インテグレーション)
具体的にはアプリケーションやインフラ環境のコードに関わる部分のテストを自動化し、常にリリース可能な状態にする。
●CD(継続的デリバリー)
リリース可能にするだけではなく、リリースまで行うケースもある。CI と CD はやる事や目的はほぼ同一で、何処までやるかだけが違う。
[基本的な機能]
| ジョブ機能 | 定形作業を自動化した小さな単位＝ジョブとする。 |
| トリガー機能 | ジョブはただ実行されるだけではなく、トリガーを設定することで「前のジョブが完了次第実行」「指定の時間が来たら定期的に実行」など、起動条件を詳細に指定できる。 |
| パイプライン機能 | 上記の機能を一連の流れ（パイプライン）とすることで、呼び出すときの記述が容易になり動きの可視化ができる。 |
[手動 or 自動]
・CI/CD ツールを実行をするには「手動」か「自動」か選べる。
・継続的な価値提供、という目線で考えた時、イベントトリガーを用いて自動実行することが多い。
・CI/CD 共に手順が複雑になっている場合はビルドパイプラインを構築し、順番に処理させる事でビルドを自動化するとよい。
ツール紹介
| Jenkins | カスタマイズ性が高く、さまざまなシチュエーションに応えられるその機能性が評価されていた。インターネットにつながっている環境だと CircleCI や GitHub Actionsのほうが扱いやすい、かつサーバーの管理も不要なため、少なくとも AWS をベースとしたシステムにおいては導入しないことが多い。 |
| CircleCI | SaaS 型の CI/CD ツール、というよりは CI/CD サービス。環境構築のコストも低く、手軽に導入できる。スケーリングが自動でされ、無料枠も用意されている。 |
| GitHub Actions | GitHub で提供している CI ツール。無料枠もある。ランナーという実行環境が提供されており、このランナーは自分で用意することもできる。ワークフローの実行回数が多いとランナー利用料が発生するため、実行数の多いプロジェクトの場合は自身で用意したほうが低コスト。 |
