Discussions
-
JIRA Software のバックログ項目に受け入れ基準を追加できるアドオン
JIRA Software と受け入れ基準 JIRA Software を使ってソフトウェア開発をしていると、受け入れ基準を設定したくなります。通常は、「説明」に箇条書きで記載したりしますね。 また、Capture for JIRA を使っているならば、テスト セッション (Test Session) で受け入れ基準とテストを管理しているかもしれません。 でも、受け入れ基準を手軽に管理したい場合はどうしましょうか。JIRA のアドオンでは、受け入れ基準機能を提供してくれるものが多数あります。 Acceptance Criteria – Definition of Done このアドオン(無料)を使うと、各バックログ項目(課題ならなんでも…
-
SourceTree で JIRA 課題や GitHub や Bitbucket Cloud Issue と連動する方法
SourceTree は、Bitbucket や GitHub と接続して、Git クライアントとしてローカルリポジトリとリモートリポジトリに対する操作を行うことができるわけですが、各サービスが備えている Issue Tracking (課題管理 / タスク管理) とも連動させることができます。 どういうことかというと、Git のコミットコメントにおいて、Issue ID を入力する「お作法」はみなさん、やっていると思います。その Issue ID を JIRA や、GitHub Issue, Bitbucket Issue へのハイパーリンクにしてくれるのです。 コミットメッセージ内の JIRA 課題 ID…
-
Confluence で多言語対応したページを作りたい
国際化ドキュメント 最初は母国語(現地語)で書いていた Confluence 文書であっても、国際化の波や、よりグローバルな戦力の加入がある場合があります。また、Confluence をオンラインマニュアルだったり、ポータルサイト、コーポレートのホームページで利用している場合などはさらに多言語化対応の課題がでてきます。 Confluence の多言語化対応 Confluence は、UI言語については多言語化対応しています。もちろん、日本語も。これらは、既定では、ブラウザのロケール(言語設定)に応じて UI 言語が選択されますので、日本語のブラウザを使っている方には日本語の UI で。英語のブラウザで使っている方には、英語 UI…
-
Bitbucket Pipelines で AWS CodeDeploy する
Bitbucket Pipelines からそのままAWS CodeDeployをつかってAWSにデプロイする設定を解説します。 Bitbucket Pipelines のフローの中で、AWS S3 にデプロイ対象を配置するのと、AWS CodeDeploy を呼び出すところがポイントです。 前提条件 前提条件は、3つです。 * S3 バケットを作成する * AWS CodeDeploy アプリケーションデプロイを用意する * AWS 権限の設定 S3 バケットの作成は、S3 を有効にするだけです。 AWS 権限の設定 AWS 権限の設定は、連携で使用するユーザーに対して、S3 と CodeDeploy の権限を与えることを指します。…
-
Bamboo から AWS CodeDeploy でデプロイする設定方法
Bamboo でのデプロイメントの設定 Bamboo では、ビルドとデプロイのプロジェクトが明確に分かれています。したがって CodeDeploy の実施は、デプロイプロジェクトで行います。 デプロイプロジェクトを新規に作成すると、デプロイ用のタスクをいくつでも設定できます。ここでは CodeDeploy を使うため、[Add task] ボタンをクリックして、「AWS CodeDeploy」タスクを選択します。 [Add task] をクリックするとデプロイで実行可能なタスクが表示されます。 「Deployment」を選択するとデプロイ関連のタスクのみを見ることができます。Docker や、Herok…
-
Bitbucket Pipelines で .NET Core 2.0 アプリの継続的インテグレーション
.NET Core 2.0 の Pipelines 設定 Bitbucket のサイドバーで[Pipelines]をクリックします。 「Start using Pipelines」の下にスクロールするとプログラミング言語、プラットフォーム別のテンプレートを選択できるようになっています。 .NET Core については、リストから選択することができます。.NET Core を選択すると、yml ファイルの設定がそのままできますので、必要最小限だけ編集しましょう。 編集箇所は、主に2箇所です。 * PROJECT_NAME: アプリのプロジェクト名を設定する * TEST_NAME: テストプロジェクトを設定する…
-
プロダクトの企画とバックログ、チーム活動を繋ぐ
プロダクトの企画 プロダクトの企画は、主に企画担当が行うことが多いです。彼らは事業としての企画からそれを戦略的にプロダクトの企画に落とし込むことが大きなお仕事になります。従って、大別してしまうと(それがいいかは別議論)、テクニカル側よりビジネス側を重視することがまず優先順位としては高くなるはずです。 そこで使われる言語は、プログラミング言語ではなく、日本語や英語のような自然言語が主流でしょう。 さらには、表現も構造化された定型とは限らず、柔軟な表現が求めれられます。 Atlassian 製品では、この辺りは、Confluence と Trello が役に立ちします。…
-
Build Once, Continuous Delivery - ビルドワンスと継続的デリバリー
アイデアをビジネス価値にし続ける 講演では実例としてデモンストレーションを実施していますが、 アイデア → ビジネス価値 を継続的に実践するための一例を提示しています。 継続的にデリバリーするためには、ビルドパイプラインやそれらの自動化だけでは不足していて、継続的フィードバックを実現する要素をカバーしておく必要があります。そこには、プロダクト戦略、バックログ戦略、ブランチ戦略、ビルド戦略そして、デプロイ戦略が一連の『流れ』として持続可能である必要があります。 『流れ』をつくる…
-
見落としがちなツールチェーンでの連携の考慮点
上図は、ライフサイクルを巡回する価値の流れを示してみたものです。 基本的にツールは、成果物にひも付きます。言い換えれば成果物に引っ張られる傾向があります。例えば、バージョン管理ツールは、ソースコードに。要求管理ツールは、要求文書に。 これらは、ウォーターフォールのように各工程に集中できる場合は、都合がよいのですが、ビジネス価値を最大化するソフトウェア開発での「価値の流れ」を重要視すると、返ってサイロを生み出してしまう一因となってしまうことがあります。 そこで、この図では、ツール(円筒の部分)とそれらの連携(パイプ)を示してみました。このときに、中心にあるような Hub…