ソースコード用リポジトリとパイプライン用リポジトリを分けるには
最近プライベートでは Azure DevOps を触っています。
業務では GitLab + Jenkins を使っているのですが、結構違いがあって面白いです。
例えば、GitLab では複数プロジェクトをグループでまとめて管理でき、グループ内のプロジェクトを横断するボードを作成することができます。
一方、Azure DevOps では複数プロジェクトを横断するボードは作成できないのですが、代わりに一つのプロジェクトに複数のリポジトリを持たせることができます。
これを利用して、一つのプロジェクト内にソースコード用リポジトリとパイプライン用リポジトリを分けて持たせることができます。
ただし、残念ながら現状、この使い方に対しての完全なサポートは得られないようです。
特にトリガーが別リポジトリの変更を検出できないようで、例えばパイプライン用リポジトリに配置した、
resources: repositories: - repository: main type: git name: Project1/Repository1 trigger: - master stages: - stage: Stage1 jobs: - job: Job1 steps: - checkout: main - task: xxx
といった YAML、或いは、
resources: repositories: - repository: main type: git name: Project1/Repository1 trigger: - master@main stages: - stage: Stage1 jobs: - job: Job1 steps: - checkout: main - task: xxx
といった YAML で、ソースコード用リポジトリの変更をトリガーにパイプラインを実行して欲しいところなのですが、これらは機能しません。
そうなると、せいぜいジョブ記述をテンプレートとしてパイプライン用リポジトリに格納しておくくらいしかできません。
azure-pipelines-master-template.yml@pipelines
stages: - stage: Stage1 jobs: - job: Job1 steps: - task: xxx
ソースコード用リポジトリにはトリガーとテンプレート参照を記述した YAML を格納する必要があります。
azure-pipelines-master.yml@main
resources: repositories: - repository: pipelines type: git name: Project1/PipelinesRepository trigger: - master stages: - template: azure-pipelines-master-template.yml@pipelines
ソースコード用リポジトリはブランチがどんどん派生していきますので、この使い方ではトリガーを変更することになったとき一斉に適用することができません。
それでもジョブ記述は分離できるので恩恵はあるのですが、不完全さは否めません。
幸い、別リポジトリの変更を検出する機能はロードマップ上 2020 Q2 (4月～6月) のリリースを予定しているようなので、もう少しの辛抱です。
ROADMAP ITEM: 1454026
- State: In Progress
- Reason: Moved to state In Progress
- Area: AzureDevOpsRoadmap\Pipelines\Build
- Iteration: AzureDevOpsRoadmap\2020 Q2
Description:
At present, you can trigger a pipeline from changes made in a single repository. This will bring in support for triggering pipelines based on changes made in one of multiple repositories. This is useful, for instance, if you manage your code in one repository and the YAML file in a different repository. Commits and work items will be computed based on all the sourced repositories.
https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1454026
テセウスの船
いやぁ面白かったですね。
第一話から最終話まで、心さん (竹内涼真) と佐野さん (鈴木亮平) の親子コンビが本当に良かった。
しかし、過去を大きく変え幸せな未来に作り変えるという『宿命』の先のいわば『運命』だったとは言え、心さんが死んでしまったのはやはり何とも複雑な気持ちです。
ラスト、佐野さんは心さんが残したタイムカプセルを開けた後でしたが、そうすると他の家族も見たってことかな。まぁ他の家族が見ても理解できず不思議に思うだけでしょうが、お母さん (榮倉奈々) はさすがに気づいたかな。
アフターストーリー、もっとたくさん欲しかった。
あと、慎吾が大人になったら澤部になってたのも複雑な気持ちです (笑)
ちなみに真犯人の田中正志 (霜降り明星 せいや)、ググってみると第二話の時点ではある意味完全否定されててウケました。
dorama9.com
たまには
遠い昔に書いた自分のブログ記事を読むのも良いものですね。
デブサミ2007に行った時の記事があってとても懐かしく思いました。
どうやら全セッションを最前列で拝聴しようとしていたようで、こいつ偉いなとか他人事のように思ってしまいましたが。
その後職場環境が変わり、徐々に自己啓発から遠のき、デブサミを始めとするイベントごとに一切行かなくなり、気付けばおよそ10年くらいたったのが去年。
去年はこのブログを開設しましたし、10年ぶりくらいにこの手のイベントの一つ PyCon にも行ってきました。(PyCon 自体は初参加)
そして先日、デブサミ2020にも行ってきました。
記憶力がかなり悪いのでデブサミ2007以降にデブサミに参加したかどうかは覚えてないのですが、いずれにしろ10年以上ぶりのデブサミです。
「全セッション最前列で！」だなんて考えもしませんでしたが、和田卓人さんのセッションだけは最前列で聴くつもりでいました。
結果は、、、デブサミ2007で同じように天野さんのセッションに臨んだ当時の私と奇しくも同じ、3列目くらいをなんとかゲットできました。
本当に久しぶりのデブサミでしたが、やはり期待していた通り、拝聴したセッションどれも本当に面白くて大満足です。
しかし、二日間とも参加のつもりでいたのに体力的にしんどくて1日でギブアップしてしまったのが唯一悔やまれます。
(もう歳なのか、、と思いましたが荷物無駄に重くしてたのが一番の原因でした。)
継続的なリファクタリング文化
↓の記事に対する投稿コメントとして書いていましたが、ブログ記事に使うことにします。
リファクタリングは積極的にするべきではありますが、綺麗なコードに正解は無いというのが個人的な見解です。
チームのみんなが読みやすい形になっていることが必要条件と思っています。
最初の例のコードも、チームによっては十分な可読性を持っているとみなされるかもしれません。
戻り値の変数化についても、IDEによる補助があるならば save メソッドにマウスカーソルを乗せるだけで同等以上の情報が得られますし、或いは戻り値に対する静的な型付けや型ヒントがあればやはり十分です。
引数が増えることを想定しなくとも、引数が増えた時にリファクタリングを当然のように行えれば良いとも言えます。
何が言いたいかというと、「継続的なリファクタリング」という文化を育むことこそが最も重要だということです。 (勿論そのためにも、リファクタリングの重要性を啓蒙するこのような記事は大変有用と思います。)
コードを読んだとき、コードに手を入れた時、もう少しリファクタリングした方が良いと感じたならば、迷わずリファクタリングできる文化・品質保証。 そのためにはアジャイル・テスト駆動開発・進化的設計、そして継続的インテグレーションが有効ですが、自身の属する組織がウォーターフォール型の開発だと、いきなり色々は難しいですね。
コードという「ドキュメント」をリファクタリングによって「コミュニケーション」に昇華させるアジャイル開発よりも、「ドキュメント」を最重要視するウォーターフォール開発の方が、その実、初期の徹底的なリファクタリングを必要としているというのは、何とも皮肉な話です。
Windows 環境の VSCode で Jest をちゃんとデバッグするハック
拡張機能を使って Jest のデバッグを行っている場合は良いのですが、launch.json を記述してデバッグしている場合、Windows 環境の VSCode と Jest のデバッグはやや相性が悪いようです。
node_modules 内の jest.js のパスが Windows とそれ以外とでは違っていたり、jest に渡すテストファイルのパス形式が unix 形式 (スラッシュ区切り) しかサポートしていなかったり。
前者はどうとでもできるのですが、後者が結構痛くて、${file} の代わりに ${fileBasenameNoExtension} でお茶を濁すのが通例となっているようですが、別ディレクトリに同名テストファイルがあると困ってしまうと思います。
ということで、launch_jest.js という JavaScript ファイルを用意し、これらの違いや制約を吸収してしまいましょう。
{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Debug Current Test", "type": "node", "request": "launch", "program": "${workspaceRoot}/.vscode/launch_jest.js", "protocol": "inspector", "args": [ "${file}", "--runInBand" ], "skipFiles": [ "<node_internals>/**/*.js", "node_modules", ] } ] }
- .vscode/launch_jest.js
if (process.platform == "win32") { for (let i = 0; i < process.argv.length; i++) { const arg = process.argv[i]; process.argv[i] = arg.replace(/\\/g, "/") } require('../node_modules/jest/bin/jest'); } else { require("../node_modules/.bin/jest"); }
これで、現在開いているテストファイルをデバッグすることができるようになりました。
拡張機能を使う場合
拡張機能を使う場合は launch.json も launch_jest.js によるハックも不要です。
ただ、拡張機能はいくつかあるものの、メンテされていないものも多いです。
現在、メンテがされてて且つちゃんと使えるのは Jest Runner だけかなと思います。
Jest Runner を使うと、テストケースを右クリックして単体でのテスト実行やデバッグ実行ができます。
私の場合は Workspace 設定 (.code-workspace) で下記のように設定して使っています。
"settings": { "jestrunner.debugOptions": { "skipFiles": [ "<node_internals>/**/*.js", "node_modules/" ] } }
Jest Run It という拡張機能も良さげなのですが、最近リリースされたばかりのためまだ完全には動作しないようです。私の環境ではデバッグ実行がエラーで失敗してしまいました。
今後に期待です。
ちなみに、インストール数ダントツ一位の Jest という拡張機能は、セーブ時に毎回バックグラウンドでテスト実行してくれるというものですが、個人的にはクセが強くて馴染めませんでした。
こんな感じでマイクロフロントエンド
目指していこうと思います。
BFF for Web は各マイクロチームが必要に応じて柔軟にメンテしていく方が良さそうな気がしてますが、実際に形にしていかないと見えてきませんね。
実開発では開発体制に合わせて徐々にサービス・フロントエンドを分割していくことになるかと思いますが、最終的にこういう形を実現できるよう、技術習得を行っていくつもりです。
シュラスコサーベル
前から欲しかったけど買う機会を逃していたアイテム。
さっきテレビで松潤と山田涼介がシュラスコやってるの観て衝動買いしてしまいました。
テレビでは窯で焼いていましたが、BBQ コンロでも出来ます。
私が買ったのは、『シュラスコサーベル２本セット』『シュラスコナイフ&フォークセット』『シュラスコサーベルケース』の3点でおよそ11,000円 (送料含む)。
結構いい値段します。ということで『シュラスコパン』はとりあえず見送り。
一見すると『シュラスコサーベルフルセット』の方がシングル幅のサーベル２本も付いてきてお得そうだったのですが、よく見るとナイフ&フォークが『シュラスコナイフ&フォークセット』のものとは違うようです。
実物を見比べたわけではないですが、絶対『シュラスコナイフ&フォークセット』の方が格好良い。
春先にキャンプ行くつもりなのでその時に活躍してもらうつもりです。
