TFSの作業項目と連動するのは欲しいなぁ。ラストのエントリです。SIerでエンジニアしてます。なった事で幅広いエントリになり、大変勉強になりました。自分としてはネタを出しきったので来年に向けて研鑽していきます。ついて考えている事をまとめます。運用DevOpsは「Develop」=「アイデア→動くソフトウェア」、「Operation」=「インシデント→解決策」という2つの作業を顧客価値向上のためコラボレーションする事です。詳細はALMってなに?をご参照ください。顧客ビジネスの価値向上がゴールではないためSIerへの浸透は時間がかかる気がします。(ちなみに、顧客のビジネス価値向上=対価安くする事、ただ働きと考えている人は頭冷やしてください。考慮しなければ詰むDevOpsの浸透に時間がかかるとは言え運用を考えずに開発すれば、インシデント対応時の調査に不都合が発生し顧客と運用担当者から指摘がきます。指摘によっては自社の評価が悪くなり継続的に仕事を頂けず自社の価値が減ります。「運用のしやすさ」を考慮するのは当然だと思うのですが。開発時になんで運用の事を考えられないか「運用の事を考慮して」は当然の事なのですが出来ていない現場をちょくちょく見ます。定義不足、タイトなスケジュールによる実装対象から外れたなどが直接的な原因ですが、根本は「運用した事がないから」ではないかと考えてます。経験があれば情報収集に困るアプリケーションは作りたくないと考えるはずですが、必要とされるスキルと知識が異なるため開発チームに所属する人は運用経験がない場合がよくあります。そんな人に運用を意識してもらうために幾つかやっていた事をあげてみます。保守開発では運用チームから人を引っ張ってくる機能拡張の時に現在システムを運用している人に設計、テスト設計のレビューをして貰いました。運用時に考慮しなくてはいけない事は設計時に盛り込みますが、システムの癖(顧客がよくチェックする箇所、システムエラーが発生しやすい箇所など)に対応するため運用の方の知識は重要でした。動作確認環境を使い不具合調査シミュレーションログ出力レベルなどの設定を運用時と同一のテスト用環境を構築し、画面間の遷移や機能間の連携のテストを実施しました。そこでシステムエラーなどが発生し、調査しずらい箇所については課題管理してログ出力レベルの見直し等を実施しました。保守運用時も開発時と同じツールを使う開発時、顧客の受入テスト以降は受入テストが運用と考えるとDevOpsの模擬練習のようなもので、顧客のフィードバックをシステムに適切に反映していると思います。ここで学んだリズムがツールによって支えられている場合、例えば、チケット管理でバックログ、バグを管理→バージョン管理にチケット番号を反映してリリース管理となっているとこのツールを使ったよいサイクルはツールがなくなると崩れてしまいます。運用になると顧客環境でチケット管理(インシデント管理)される事が多いためこの旨いサイクルが崩れてしまいます。開発時に使っている環境をそのまま顧客環境で再現するもの手ですが、他社との連携が難しくなります。そのため、ローカルな環境にツールを準備するのはDevOpsを考慮するとよろしくないはずです。私の考えている同じツールを使うという所に見事にマッチしていると思います。クラウド上でデータを管理するため顧客との調整は必要と思いますが、システムの特性によっては可能と思います。15日目のエントリです。SIerでエンジニアしてます。今日はTFSのメールによる通知、プロジェクト警告の設定と、カスタマイズについてです。作業項目の変更、ビルドイベントなどのTFSからの通知をメールで受け取る事ができます。ゲートチェックインが導入できないプロジェクトで自動ビルドが失敗した場合などに便利ですね。失敗時にメールを受け取るのも寂しいのでメールにメッセージを込めるのもありかと。いうことでカスタマイズしてみましょう。このエントリの結論カスタマイズしてこんな通知を受け取ることができます。管理コンソール」を起動し「アプリケーション層」→「通知の設定」をクリックします。送信用メールに必要な設定を行います。TFS2012から認証が必要なSMTPサーバへ送信するための設定が画面から可能になっていますねー(ここでメール送信をテストする機能が欲しい。起動し「チーム」→「プロジェクト警告」をクリックします。アクセスのプロジェクト警告が表示されます。「自分用の警告の送信先(編集)」をクリックして送信先メールアドレスを設定します。あとはどんな通知を受け取るか設定します。高度な警告の管理ページを見ればわかりますがデフォルトでの「ビルドが完了したとき」と「ビルドの終了」の違いは以下の通り。個人用設定の画面の「高度な警告の管理ページ」をクリックします。(コントロールパネル経由で行く方法が正しいのかも知れませんが手間なので紹介しません)高度な管理ページの「チーム個の警告」の対象となる警告を選択します。今回は「ビルド個の警告」です。新規作成から画面に従っていけば作成できますでの省略します。本文のカスタマイズTFSからのメールはXLSで元データから加工されます。そのテンプレートは以下の場所にあります。Tier\TFSJobAgent\Transforms\1041送信形式ごとにテンプレートがあります。(どの形式になっているかは、高度な管理ページから参照できます)今回は、「ビルドが完了したとき」に「HTML」で送信する設定がされているとして「BuildCompletedEvent.xsl」を編集します。(AAをメールにつける場合、フォントを指定する必要があるのでHTMLにする必要があります)XSLのため、慣れていないと厳しいですが見ているとビルド失敗の条件分岐がわかります。'Failed'">これを使ってテンプレートを以下のように編集します。編集時は管理者権限が必要になるので注意。GitHubんで、ビルドエラーをしてみると。10日目のエントリです。SIerでエンジニアしてます。コードスニペット便利ですね!最近まで「コードスペニッド」、今まで「コードスニペット」って言ってて恥ずかしい思いをしました!今日はコードスニペッドについてまとめてみます。コードスニペッドって?皆様当然知っているとは思いますが。入力してタブキーを押すとと展開される入力補助機能です。自分で作成したコードスニペッドを登録する事もできます。チーム開発において少し大きな開発チームになるとコード規約を作成して、何々を使うときにはこう記述して、何々を作成する時はああ記述してください、アナウンスする事になったりします。いったルールや規約は静的コード解析でチェックする、レビューでチェックするというものありますが最初からルールどおりのコードが手軽にできるのが一番です。登録して使ってもらうのがよいかと思います。コードスニペットの作成の仕方しかしコードスニペットはちょっと手で書くのは大変です。そのため以下の拡張機能を利用します。extension簡単ですが手順を説明しておきます。extensionをダウンロードしてインストールします。対象部分の切り出しスニペットに切り出す箇所を選択します。Snippet」をクリックします。初期設定の入力スニペット編集画面になります。スニペットの編集画面と、スニペットのプロパティが表示されます。初期設定として以下の3つを入力します。エディタの「Snippet」ファイルの名称を指定します。プロパティの「Descirption」スニペットの概要を指定します。コードスニペットマネージャーで表示されます。プロパティの「Shortcut」スニペットを呼び出すためのショートカットキーを指定します。編集項目の入力スニペット呼び出し時、編集可能な箇所を指定します。Replacement」をクリックします。するとエディタの下部に編集用項目が増えます。Snippets」に保存します。これで「Shortcut」と指定した文字+tabキーで使うことができます。便利なスニペットに期待するところさていかがでしょう。コードスニペットがこれで大分使いやすくなるはずです。Snippets」に登録するか、スニペットマネージャーを利用して登録しなくてはいけないのが手間ですね。ソリューションのどこかに保存しておいたら自動でそのスニペッドが利用できるようになるといいなーと思います。6日目のエントリです。SIerでエンジニアしてます。いつもは技術系ですがALMということで今回は趣向を変えて、ツールを使わなかったとあるシステムのライフサイクルを振り返りつつ、どうあるべきだったか考えてみようと思います。前提ウォーターフォールです。マイクロソフト製品オンリーのプロジェクトだったのでTFSですが適宜ALMツールに置き換えてください。あとフィクションです。誕生とある業務システム。本番運用開始と同時に新規開発での多発する仕様変更と品質の問題に疲弊したメンバーがリタイヤした現場。稼働直後にプロジェクトへアサインされた訳ですが色々な課題がありました。バージョン管理されていないソース、設計書VSSが存在していましたがテストが完了したものから管理台帳に記載してVSSにチェックインするという謎ルールでした。ビルドサーバがない「yy.dll」「xx.exe」が50個。バックログは大小100近くありました。一つのバックログはテキストファイルや変更要望書という形で単独で存在しており、まとまったものはありませんでした。新規開発直後は人員も多く人力で品質、ミスを防いでいるかもしれませんが人数が減るとどうしても手薄になるのですぐに自動化、ツールの導入をした方がいいです。私は知識と権限の不足からどの課題にも何も対応せず運用していましたが、どの課題についても一度は障害を伴った事故を発生させ、ビルドサーバ、管理台帳を顧客と調整し作ることになりました。青年期3年が経過しました。大規模な改修を半年に一回。顧客も保守メンバーも慣れてきました。システムも安定稼働し、顧客にも余裕が産まれて改善が始まりました。過去の保守開発のどのバックログにどの程度の規模対応したかを参照し、新しい保守開発の工数見積をするよう顧客から要望がでました。過去の保守案件は「参考」程度にはしていましたが、トータルでどれだけのコストだったかのみしか記録していない事、個々のバックログに対してどの程度コストがかかったかが記録されていなかった事から実績からの見積はできませんでした。(TFS2012ではタスクに実績時間をつける項目はないのでカスタマイズする必要があります)バックログと改修範囲のトレーサビリティ業務のルールも満遍なく改修される事はなく、集中的に改修が入る箇所は決まってきます。バックログの種類によって影響範囲も決まってきます。この影響範囲をベンダーの調査工数削減のため、過去保守案件の実績から見える化をする要望が出てきました。レコード件数が1000を越え、インシデントを管理していた別の台帳も2000件ぐらいになってました。Excelで1000件を越える行数ファイルではとても作業になりません。実績工数は概算になり、トレーサビリティは記録しておらず、台帳だけはAccessにツールに変更しました。この時点でTFSを知っていたらコストがかかっていても移行しましょう!と顧客に提案していたかもしれませんが運用手順も固まっていて移行コストは大きかったのではないかと思っています。年月が経ちついに再構築の話が出てきました。初期メンバーは全て抜けて再構築時の事を知らないメンバーのみとなりました。長年運用しての課題が人の記憶にしか残っていない課題台帳はレコードが大きすぎるという事から、顧客リーダー変更時に一度破棄されました。その結果長年付き合ってくれたメンバーの中だけにシステム運用時の課題、設計上の歪みが残る事になり新システムには反映されませんでした。時間の経過で発生する課題に対応するために正直ツールではなくプロジェクトの運用がよろしくなかったと思っています。TFSを入れていたら変わっていた「かも」しれません。目的があってのツールですが未熟なプロジェクトならツールの背景にある思想を学ぶことで良いプロセスになる事もあるのではないのでしょうか。TFSやALMの思想について聞いて「いいかも」と思ったら勉強しつつ導入してみてはいかがでしょう。「拡張機能と更新プログラム」から追加してください。項目に「TypeScript」があります。