Jira core をワークフローツールとして使う
背景
Jira core を workflow として使うときのメモ。日々更新。
なぜ Jira を使うのか
決められたフローに従って処理をしてほしい。終わったら、ボタン一つで次の人にアサインして欲しい。
用語
プロジェクト
一つのワークフローを持つことができる。またボードを持つことができる。
ボード
ステータス上の課題（チケット）をみることができる。カンバンボード。
ワークフロー
ステータスとトランジッションからなる。 ワークフローの各ステータス上を課題（チケット）がトランジッションに従い移動する。 後述するワークフロースキームに紐づくとアクティブとなる。コピーされたワークフローは非アクティブの状態である。非アクティブでないと編集できない。
課題
課題（チケット）はタスクのような単位。課題はステータスや、課題フィールドといった複数の属性を持つ。
ステータス
課題（チケット）が持つことができる状態。課題はそれ以外に、課題フィールドとよばれる、複数の属性をもつ。
課題フィールド
課題がもつ属性。解決状況や、担当者（アサイニ）や報告者などがある。
担当者
課題フィールドの一つで、現在その課題に割り振られている人。アサイニ。課題にはそのほかに報告者という人もいる。
報告者
課題フィールドの一つで、その課題を作成した人。最後担当者を報告者に割り当てて確認してもらい完了するなどするときに使う。
トランジッション
ステータス間の方向性を持ったリンク。一つの状態から複数の選択肢がある場合には、複数のトランジッションを持たせることできる。トランジッションの名称は選択肢が一つしかないなら特に気にする必要はないが、複数ある時には、ステータス先を見て決めるよりもトランジッション名を見て決めるので、重要となる。
事後処理
トランジッションを行ったときに何か処理を行うかどうか。少なくともステータスは変更されるので一つ以上のの事後処理はあることになる。ステータスによって担当者が一人に決まるときは、ここに課題フィールドの変更として追加すればよい。
ワークフロースキーム
プロジェクトのステータスの種類を示す。ワークフロースキームというよりステータススキームといったほうが分りやすいだろう。アクティブであるということは現在プロジェクトで使われているということになる。コピーしたものは非アクティブとなる。また「ワークフローの追加」をすることで、「追加された」ワークフローはアクティブになり、これまで使っていたワークフローは非アクティブになる。このとき二つのワークフローステータスから新しいワークフローのステータスへ既存の課題を移し替える「調整」という作業が発生する。
Jira の slack 連携で使うslackアプリ
背景
気が付けば、Jiraの slack アプリが二つも入っていた。何かおかしい。
二つのアプリの違い
Jira Cloud
新しい。チャンネルごとの設定ができる。
チャンネル設定のやり方
- はじめに設定したいチャンネルに入る。
- プライベートチャネルなら、
/invite jiraをする - コマンド
/jira connectで接続する（チャンネルごとに初回のみ） - コマンド
/jira manageで現れたリンクをクリックする。
ダイレクトメッセージ設定のやり方
- はじめにjiraのダイレクトメッセージに入る。
- コマンド
/jira connectで接続する（初回のみ） - コマンド
/jira manageで現れたリンクをクリックする。 - JQLにて
assignee = "your@mail.address"として save すると幸せになれるかも。（ダブルクオートを忘れない）
参考： ja.confluence.atlassian.com
JQLのフィールド
Jira Server Alerts (Legacy)
古い。チャンネルごとの設定ができない。
まとめ
Jira Cloud を使おう
DataPortal のコピー
背景
DataPortal は個人（社内）で使うのは素晴らしいが、これを使ってビジネスでスケールアウトさせようとすると、いろいろと問題が出る。 とりあえず、コピーをして複製を作り、その複製に対して設定を変えるという手作業でなんとかしのげそうなのだが、コピーそのものがうまくいかない。
コピーの理解
DataPortalとデータソースは別物
DataPortalをコピーすると、当然紐づけられているデータソースもコピーされると思うだろう。 実際、自分で作った（カスタム）データソースは自分でコピーする際に、デフォルトで選択肢として表示される。 ところが、他の人がDataPortalをコピーしようとすると、そのデータソースが共有されていない場合、 デフォルトの選択肢として表示されない。
解決策
コピーする人にデータソースを共有する
データーソースの共有は閲覧者としてのみでOK.。ダウンロードや印刷、コピーを禁止しておく。 一方で、データソースの先のアクセス権は、データソースの「データの認証情報」が「オーナー」にセットされていれば、データソースへはオーナーの権限でアクセスしに行くので、問題ないだろう。 DataPortalそのものはその作成者（複製者）の権限でデータソースにアクセスしに行くので、これらのコンボ技でDataPortalが見える人なら閲覧することが可能となる。
コピーした人が複製されたDataPortalの共有権限を設定する
複製元のDataPortalの共有設定は複製先のDataPortalに継承されない。ゆえに他人に見てもらうのであれば、複製されたDataPortalの共有設定を忘れずにする必要がある。
Google Analytics の tracking ID もコピーする。
コピーされないので、こちらもコピーする。
まとめ
- DataPortal とデータソースは別物
- だからコピーにはデータソースの共有も必要（閲覧者でOK）
- 複製されたDataPortalの共有設定は忘れずに。
Jira Software Cloud と GitHub の連携
背景
Jira Software Cloud と GitHub の連携に関して、検索すると古い記事が出てくる。 Atlassian の公式のページの情報も古い記事なので注意。OAuth や、DVCS アカウントというキーワードが出ていれば全て古い。
解決策
すべては、
の2018年10月4日以降の記事を参考にすべし。
すなわち、
をJira側でインストール（Jiraの管理者権限が必要）し、そこの設定リンクから、github側の設定に飛ぶ（githubの管理者権限が必要）
連携後の使い方
BigQueryで、1000円分の切手問題を解く
背景
方法
実行は慎むこと。データ参照は0バイトだが、7000秒たっても（現時点）結果は出ない。こんなおバカなクエリをBQ様に投げて心が痛い。
WITH num_list AS ( SELECT n FROM ( SELECT GENERATE_ARRAY(1,1000) a ) CROSS JOIN UNNEST(a) AS n), n1 as (select n from num_list where n * 1 <= 1000), n2 as (select n from num_list where n * 2 <= 1000), n3 as (select n from num_list where n * 3 <= 1000), n5 as (select n from num_list where n * 5 <= 1000), n10 as (select n from num_list where n * 10 <= 1000), n20 as (select n from num_list where n * 20 <= 1000), n30 as (select n from num_list where n * 30 <= 1000), n50 as (select n from num_list where n * 50 <= 1000), n62 as (select n from num_list where n * 62 <= 1000), n82 as (select n from num_list where n * 82 <= 1000), n92 as (select n from num_list where n * 92 <= 1000), n100 as (select n from num_list where n * 100 <= 1000), n120 as (select n from num_list where n * 120 <= 1000), n140 as (select n from num_list where n * 140 <= 1000), n205 as (select n from num_list where n * 205 <= 1000), n280 as (select n from num_list where n * 280 <= 1000), n310 as (select n from num_list where n * 310 <= 1000), n500 as (select n from num_list where n * 500 <= 1000), n1000 as (select n from num_list where n * 1000 <= 1000) select n1.n as nn1, n2.n as nn2, n3.n as nn3, n5.n as nn5, n10.n as nn10, n20.n as nn20, n30.n as nn30, n50.n as nn50, n62.n as nn62, n82.n as nn82, n92.n as nn92, n100.n as nn100, n120.n as nn120, n140.n as nn140, n205.n as nn205, n280.n as nn280, n310.n as nn310, n500.n as nn500, n1000.n as nn1000 from n1 cross join n2 cross join n3 cross join n5 cross join n10 cross join n20 cross join n30 cross join n50 cross join n62 cross join n82 cross join n92 cross join n100 cross join n120 cross join n140 cross join n205 cross join n280 cross join n310 cross join n500 cross join n1000 where n1.n * 1 + n2.n * 2 + n3.n * 3 + n5.n * 5 + n10.n * 10 + n20.n * 20 + n30.n * 30 + n50.n * 50 + n62.n * 62 + n82.n * 82 + n92.n * 92 + n100.n * 100 + n120.n * 120 + n140.n * 140 + n205.n * 205 + n280.n * 280 + n310.n * 310 + n500.n * 500 + n1000.n * 1000 = 1000
結論
バカは俺一人で十分
bigquery の int64 への cast は切り捨てではない
すなわち、
select cast(1/2 as int64)
は切り捨てではなく、丸められ
1
となる。
（今更ながら知る。。。）
切り捨ては、floor を使おう。
