Posts in tetsuro.takao

ALM（Application Lifecycle Management）の目的はシステムの継続的な配布（と統合）です。継続的デリバリを考慮した場合、製品の配布パッケージ（リソースとコンパイル済みコード）、開発環境プロジェクトのリポジトリ、ステージングやリサーチ用のソースコードの3つをどのように連携するかが肝になります。Microsoft製品の場合、これらが容易に連携できるようになっています。 各種リソースの連携 Visual StudioでWeb Appを作成し、Azureのプロダクション環境へ発行、同じくVisual StudioでWeb AppをVisual Studio Team Servicesへ登録しソース管理を行う方法を紹介します。 まずテンプレートから作成したWeb Appをそのままソリューションエクスプローラーで右クリックして[公開]を選択し、Azureのプロダクション環境へ発行します ソース管理へ登録 Web […]

ソース管理ツールは、製品のロードマップがあって組織内の様々なプロセスの後に形成されるALMを基盤として、その上で利用するものですから、それらの先行作業なしにツールを利用することはできません。しかしながら、多くの組織ではバージョン管理ツールを使うことに執心し、製品戦略との兼ね合いや構築プロジェクト完了後の継続的デリバリを意識すること無く、納品後のソースコードそのものがファイルサーバーに置かれていたりします。この記事では、ソース管理ツールが製品戦略の中でどのような役割を果たし、製品の継続的デリバリがどのようになされるのかについて解説します。 ALM ALM（Application Lifecycle Management）は、継続的デリバリには欠かせない作業です。ALMはPLM（Product Lifecycle Management）の一部であり、サービスのリリース時期、機能の拡張時期といったビジネスに直結する要素と分離された状態では、機能を実現する際の技術検証や懸念事項が犠牲にされプロジェクトのリスクが高まります。 ALMツール PLMで定義された製品化カタログはALM側でユーザーストーリーに置き換え、PLMで計画されたリリース単位、リリース時期をALM側でイテレーションに置き換えて、機能以外のドキュメントっ作成なども考慮したタスク群の入れ物となるバックログを作成していきます。その作業を支えるのがALMツールであり、いくつかの製品が販売されています。 ALMでは、ソースコードやバッチなどのリソース（≒プロジェクトの成果物）の状態を定義し管理します。設計文書などの状態なども定義し管理します。 ソースコード等のリソースの状態の定義とは、イテレーション内のユースケースを構成する複数のタスクのうちプログラムやバッチとして定義したタスクをフィーチャー（機能）として複製し量と質を管理していきます。量の管理とは、機能単位でソースコードが追加された、改修された、拡張された等を指し、アジャイル開発プロセスを採用している場合はできる限り1日単位（8h程度）のタスクにすることを推奨します。 また質の管理とは、その機能はどのような作業（コードレビューが終了した、単体試験が終了した等）で構成されているのかといった質の単位を定義し管理します。