スピーカー | 成績証明書 |
| セルカイ・オルメス | こんにちは、Seagate の Serkay と Fred です。今日は、JSL スクリプトを管理するために JSL エコシステムを構築した方法について話します。 |
| そのため、JSL スクリプトのソースであるソース管理を管理し、配布するために Git を使用しています。 それが今日の話の主なポイントになります。 |
| ただし、それに加えて、PowerPoint 統合のための VBA、クラッシュ ログ収集、単体テストについても説明します。 早速概要に飛んでいきます。 |
| そこで最初に話したいのは、JSL の歴史についてです。 私は約 10 年ほど JSL でスクリプトを作成してきました。 |
| 私たちは現在の状況に非常に満足していますが、ここに到達するまでにかなりの時間がかかりました。私たちの経験のマイルストーン、これまでに何をし、なぜそうしたのかについて話したいと思います。 |
| 次に、Git について、Git を使用して JSL スクリプトのソース管理を可能にした方法、および Git を使用してさらなる機能を構築できるようにした方法について説明します。 たとえば、Git を有効にすると、 |
| スクリプトの監視などの機能を追加できます。 つまり、開発者はスクリプトが使用されていることを知り、使用状況を監視できることがわかります。 |
| そしておそらくもっと重要なのは、ログも収集できることです。 スクリプトがクラッシュした場合、開発者はそれを知り、戻ってそれらのバグを修正できます。 そして、次のことができます... |
| さらに一歩進んだ機能をもう 1 つ追加できます。 スクリプトがクラッシュしたことがすでにわかっている自動バグ チケットを作成することもできます。 したがって、そのバグチケットを自動的に作成できます。 また、JIRA や Atlassian などの追跡ソフトウェアを使用して、これらのチケットを追跡できます。 |
| 最後に、これまでに学んだベストプラクティスと教訓を紹介します。 |
| それで、 |
| 付録には、これから説明するスクリプトのマニュアルもあります。 画像をPowerPointにプッシュできるスクリプトです。 |
| そして、そのための非常に詳細なマニュアルがあります。ここで話す内容、データ、スクリプトはすべて入手可能であることだけをお知らせしておきます。 |
| これらは、ここの参考セクションのパブリック リポジトリに掲載されており、必要に応じてそこにアクセスしてそれらのファイルを取得することができます。 それでは始めましょう |
| ここで簡単な歴史を説明します。 それで 10...私は約 10 年ほど JSL と仕事をしてきました。そして、まず始めました。 |
| 非常に基本的なもので、JSL スクリプトについてはあまり知りませんでした。 |
| そして、それを始めてみると、適切なソース管理が必要であり、スクリプトを配布する適切な方法が必要であることがわかります。 |
| つまり、JMP スクリプトの利点は、参入障壁がないということです。 したがって、文字通り手動でプロットを作成してから、スクリプトを取得することができます。 それはあなたのために書かれたものです。 |
| また、JMP.com の Community to JMP を使用して質問し、回答を得ることもできます。 |
| そしてあなたは...スクリプトが非常に効率的であるため、仕事を非常に効率的に実行しているため、人々は気づくでしょう。 彼らはあなたがどのように物事を行うかを尋ねると、あなたは私がそのための台本があると言うでしょう。 そして彼らはそうするだろう |
| 「それを教えてもらえますか？」と尋ねてください。 そして、そのつもりはなかったにもかかわらず、突然あなたは開発者になってしまいます。 |
| 次に、スクリプトの配布に対処する必要があります。 最初に思い浮かぶアイデアは、単にそれらを取り付けることですが、これはひどいアイデアであり、私はかなり長い間そうしてきました。 |
| それがなぜ良い考えではないのかは明らかです。スクリプトを添付して送信し、翌日には |
| リビジョンを修正してから再度送信する必要があり、ユーザーが次のリビジョンを使用するかどうかさえわかりません。 したがって、ここでは要点を説明するだけです。 |
| 最近、同僚からメールを受け取りました。彼は 2017 年に作成したスクリプトについて言及していました。ちょうど自分のスクリプトにこれらの番号を振っていました。 |
| バージョン番号。これは良い考えではありません。 そのため、3、4 年後にこのスクリプトが復活し、更新されていないため、人々はまだ 3 年前のスクリプトを使用していることに気付きます。 |
| この問題を解決する 1 つの方法は、共有ドライブを使用することです。これは、ドライブ内の人々とのやり取りに基づいています。 |
| Discovery Summits は、多くの人、多くの企業がこれを使用しているということです。 そこで開発者がやるべきことは、 |
| スクリプトを共有ドライブにダンプすると、ユーザーは共有ドライブから直接プルすることになり、配布の問題の半分は解決しますが、ソース管理については何もしません。 コードに加えた変更を追跡することはできません。 |
| それが、私たちが実際に Git に移行した理由です。 これは私たちにとって画期的なことであり、多くの機能が可能になりました。 では、Git を使って何をするかというと、開発者はスクリプトをリポジトリにプッシュし、 |
| ユーザーはスクリプトを Git から直接プルすることになります。 これは私たちにとって大きな改善であり、クラッシュ ログを収集できるようになり、 |
| スクリプトの使用法など。サミットから学んだことをさらにいくつかお話したいと思います。 これらは私のスクリプト スキルを向上させるのに非常に役立ち、2018 年にサミットに参加し、表現などについてかなりのことを学びました。 |
| これらのプレゼンテーションはスクリプト作成スキルに役立つため、人々は戻ってそれらのプレゼンテーションを聞きたいと思うかもしれません。 |
| そして、私たちにとってもう 1 つのマイルストーンはテストでした。 そこで私は、昨年のサミットでの単体テストに関する講演に触発されました。これにより、スクリプトを公開する前に自動的にテストできるようになります。 |
| 今日は主に統合テストについて話します。なぜなら、単体テストは...単体テストは必要ですが、十分ではないからです。 |
| 単体テストを実行できるため、すべてのモジュールをテストでき、正常にチェックアウトされます。 しかし、それらを組み合わせると機能しません。 ここに示すように、クラッシュします。 おそらくそれぞれの引き出しはテストされていますが、それらを組み合わせると動作しません。 |
| 開発者にとって非常に役立つ優れた機能の 1 つは、ログ収集に関するものです。 |
| スクリプトがクラッシュしたことと、それがどのようにクラッシュしたかを知ることは非常に役立ちます。 ユーザーからログを収集することでこれを行うことができ、戻ってスクリプトを修正して変更をプッシュすることができ、ユーザーは修正されたスクリプトをすぐに入手できるようになります。 |
| そして、私たちが最近展開している最後の機能は、自動バグレポートに関するものです。 すでにクラッシュ レポートがあるのですから、その情報に基づいて行動してみてはいかがでしょうか? そこで私たちは自動化された |
| 監視 |
| システムはクラッシュ ログを追跡し、開発者がバグ レポートに取り組むことができるように自動的にバグ レポートを作成します。 さらに、ユーザーをウォッチャーとして追加すると、誰かが問題に取り組んでいることをユーザーに知らせることができます。 つまり、それは解決します |
| ユーザーと開発者の間の情報ギャップを解決します。 |
| これはタイムラインを示しています。 |
| 個々の項目について説明しますが、Git から始めて、これを簡単に構築して、Fred に話してもらいます。 |
| 163084 | わかった。 |
| それで、 |
| Git は単なるバージョン管理システムであり、バージョン管理という言葉は使いません。 実際のところ、私が言いたいのは、たとえ自分のローカル コンピューター上でのみ Git を使用している場合でも、Git は事実上、無制限のやり直しを可能にしてくれるという点で役に立ちます。 それ |
| 過去数週間に行った作業の一部が間違っていたと判断し、数週間前の作業に戻りたい場合に備えて、ファイルのリビジョンを追跡し、古いファイルに戻ることができます。 |
| つまり、Git はローカル コンピューターにインストールする単なるソフトウェアです。 リポジトリを作成し、そのリポジトリを他のリポジトリに投稿できます。 |
| GitLab や GitHub など。 TortoiseGit は、ローカル マシン上で作業を簡単にする GUI インターフェイスです。 それでは、セルカイ、次のスライドを開いていただければ。 |
| したがって、私が開発者に使用してもらおうと試みたモデルは、開発者のローカル コンピューター上にあります。 ローカルの開発者に、Git クライアントをインストールして開始してもらいます。 |
| ローカル PC 上のファイルのバージョンを管理します。 ユーザーがその習慣を身に付けたら、リモート リポジトリに接続できるようになります。 |
| Git はリモート リポジトリ、SSH 一般、またはその他の方法で接続し、プッシュできます。 |
| Git データベースのコピーをリモート リポジトリに保存します。 リモート リポジトリ上で起動すると、HTTP Web サーバーがバックアウトと JMP を共有できるようになります。 |
| その後、URL と HTTP...HTTP Web サーバーをポイントし、そこからスクリプトをロードできます。 そのため、共有ドライブを使用する代わりに、Git リポジトリへのプッシュによって設定された HTTP Web サーバーを使用しています。 |
| そして、以下の箇条書きは、その利点とそれがどのように正確に機能するかを指摘するだけです。 |
| 次のスライドに進むことができます。 |
| セルカイ・オルメス | それで、フレッド、私がここを引き継ぎます。非常に基本的な図の実装をお見せします。スクリプトは参考資料で入手できます。 |
| それで、 |
| これは非常に基本的なコードになります。 ここで示しているのは、開発者が開発中のコードです。 それは最低限のことですよね。 これは、「Hello World」というダイアログ ボックスが表示されるだけです。 |
| そして、開発者がこのコードをユーザーに渡したいと考えているとします。 したがって、このコードを与える代わりに、開発者が渡すのはこのコードです。 |
| これはリポジトリへのリンクです。 つまり、これはそこに存在する hello JSL スクリプトのリポジトリです... |
| リモートリポジトリ内。 ユーザーが行うことは、ただ掴むだけです...ユーザーは |
| URLからスクリプトを取得します。 つまり、これは静的コードです。 変更の必要がないため、開発者はいつでも必要に応じてスクリプトを変更できますが、ユーザーは何もする必要がありません。 ここではイラストを示しますが、全画面表示にしたいだけです。 |
| これが特定の GUI (GitHub Desktop の取得) でどのように機能するかを示しているだけです。 それで、あなたがすることはこれをインストールすることです |
| コンピュータにソフトウェアをインストールしてローカル リポジトリを作成すると、行った変更が追跡されます。 たとえば、この例では、次の hello JSL スクリプトを作成しました。 |
| このソフトウェアは変更があることを認識し、自動的に強調表示します。 そして、まずそれをローカル リポジトリにコミットします。 |
| これにより、それらがローカル リポジトリにプッシュされ、次にそれがリモート リポジトリであるオリジンにプッシュされます。 次に、それをリモートにプッシュして、ユーザーが使用できるようにします。 |
| これを実行すると、ユーザーはこの新しいコードを取得できるようになります。 そして、ここでユーザーの役割に戻り、これがスクリプトであり、ユーザーが実行されます。これを実行すると、ダイアログボックスが表示されます。 つまり、リポジトリから取得したスクリプトを実行していることになります。 |
| そこで、PowerPoint にも関連する、より高度なコードを使用して、これをもう少しわかりやすく説明します。 |
| そのため、人々は JMP で多くの分析を行いますが、それでも多くの人は、結局のところ、その結果を PowerPoint にプッシュしたいと考えています。 JMP にはいくつかのプッシュ機能があることはわかっています |
| 画像を PowerPoint に直接保存できますが、もう少し...もう少し洗練されたものが必要でした。 私たちはそうしたいです |
| PowerPointのテンプレートを管理します。 PowerPoint 内でさらにいくつかの作業を行い、スライドごとに配置する画像の数などを決定したいと考えています。 |
| これを行うには、まず JMP を PowerPoint に接続する必要があります。これは実際には非常に簡単に実行できます。 |
| 非常に良い方法なので、JMP を離れる必要さえありません。 したがって、PowerPoint の実行可能ファイルがどこにあるかを見つけることができます。通常は、Program Files の下にあります。 |
| 次に、この PowerPoint 実行可能ファイルをトリガーするバッチ ファイルを作成すると、実行する PowerPoint ファイルが取得され、そのまま実行されます。 したがって、これらすべてを JMP で行うことができます。 基本的に、これは PowerPoint 実行可能ファイルを検索します。 |
| そして、それを見つけると、それをこのバッチ ファイルにバンドルします。 実行する PowerPoint へのパスも含まれています |
| そしてマクロなので、PowerPoint 内で管理を行うためのマクロが PowerPoint に組み込まれます。 それで、これがあなたがする方法です |
| JMP を PowerPoint に接続すると、そのためには JMP をそのままにしておく必要があります。 しかし問題は、そもそもこの PowerPoint ファイルをどのようにしてユーザーに提供するのかということです。 あなたは出来る |
| これを自動的に管理し、同時に PowerPoint のソース管理も行いたいので、これは理想的ではありません。 したがって、それは良い候補である必要があります。エコシステム全体のかなりの部分を占める必要があります。 外に置きたくないですよね。 |
| もう 1 つの要件は、スクリプトを実行するたびに PowerPoint をダウンロードしたくないことです。 したがって、画像リポジトリ内で変更が加えられた場合、または PowerPoint に何か新しい点があった場合にのみ、PowerPoint をダウンロードする必要があります。 |
| したがって、これを行う方法は、この小さな JMP スクリプト (作成日を示す JMP コマンド) を使用することです。 ここで私がやっていることはチェックすることです |
| ローカルファイルの日付。 したがって、ローカルの PowerPoint がリポジトリにあるものよりも古い場合は、それをダウンロードします。 それで |
| HTTP リクエストを使用して PowerPoint をダウンロードします。 |
| こんな感じです。 したがって、ローカル コンピュータで PowerPoint を確認するだけです。 存在しない場合は、HTTP リクエストを使用してリポジトリから取得します。 存在する場合は日付を確認し、古い場合は引き続きアクセスします。 |
| 新しいものを引っ張ります。 つまり、ここでの重要な点は、PowerPoint を JMP 環境にシームレスに統合できるため、表や画像などの結果を JMP にプッシュできるということです。 これらすべてをソース管理を壊すことなく実行できます。ここでデモを示します。 |
| したがって、これは、たとえばユーザーに提供するコードになります。 繰り返しますが、これは静的コードです。 実際には、スクリプトでリモート リポジトリにリンクする URL 以外には何もありません。 それでそれは行き、それを掴みます |
| リポジトリからの JMP スクリプトとそれらのスクリプトが再び利用可能になり、リファレンスから取得するだけで済みます。 |
| 開発者側から見ると、これが実際のスクリプトです。 これは開発者が開発したスクリプトです。 |
| 彼または彼女はそれをリモートリポジトリにプッシュします。 このスクリプトの優れた点は、ここでいくつかの機能を簡単に指摘したいことだけです。 |
| たとえば、これを見てください。 これはスタンドアロンのテキスト スクリプトなので、PowerPoint ファイルや追加のスクリプトを配布する必要はありません。 |
| 別々に。あなたが行うことは、スクリプト内でそれらをリンクすることであり、それらはここのリポジトリ内でリンクされます。 |
| パワーポイントも含めて。 したがって、このスクリプトはすべてのディストリビューションを管理します。 そこで、PowerPoint を取得します。 |
| 必要に応じて、他の追加ファイルを取得します。 したがって、すべてがスクリプトにバンドルされているため、スクリプトがすべての管理を行います。 それでは、早速お見せしましょう。 これを引き戻します |
| そしてそれを全画面表示にします |
| はっきりと見えるように。 これは、PowerPoint を自動的に起動するデモになります。 |
| 特定のケースに対応します。 このスクリプトが行うことは、テーブルからパスを取得することです。これは、多くの画像パスを含む JMP テーブルであり、これらはこの特定のパスを参照しています。 |
| サーバーにアクセスし、それらのパスを取得し、ここで強調表示されているパスだけを取得して、PowerPoint にプッシュします。 |
| これを実行するだけです。試してみたい場合は、このスクリプトを利用できます。 これは完全に機能する便利なスクリプトです。 それで、私はこれを実行しています |
| スクリプトはここにあります。 繰り返しますが、これはリポジトリを参照しています。 したがって、行スクリプトはなく、リポジトリから取得するだけです。 これを実行すると、コードが取得され、ダイアログが実行されます。 |
| そして、これを実行するだけです。 詳細については説明しませんが、一度実行すると、PowerPoint が自動的に起動されます。 |
| そして PowerPoint が起動し、それが始まります...ここでスライドを構築しています。 20 枚の画像が取得されます。これには 10 ～ 20 秒かかります。その後、PowerPoint が表示されます。 |
| 終わり。これがあなたが入手する PowerPoint であり、すべてが自動的に行われ、すべてがリポジトリから取得されたものです。 |
| それで、次は何でしょうか？ このパワーポイントをどのように修正しますか? したがって、テンプレートにいくつかの変更を加えたいと思います。 そして |
| 詳細については付録を参照してください。ただし、私が説明したいのは、 |
| PowerPoint のスクリプト。 そして全画面表示に行きます、 |
| これを実行するだけです。 私たちが始めるのは、前のスライドで残っているものです。右、これらの画像がありました。 |
| 私がやりたいのは、要点を説明するだけの簡単な方法でテンプレートを変更することです。 それで、あなたは...に行きます |
| マクロに移動し、下にスクロールして変更したい項目を見つけます。ここで簡単な変更を行います。 強調するためにヘッダーの色を変更します。 それで、これを変更します |
| そして |
| それを保存。 そして、これはリアルタイムで進行しています。 |
| これを保存してスライドを削除すると、これをリポジトリにプッシュするため、より速くリポジトリに送信できるようになります。 |
| 次に、Git GUI を使用してこれをプッシュします。 リポジトリに入ります |
| ユーザーがそれを利用できるようになります。 したがって、すべてのユーザーが即座に変更を取得できるようになります。 つまり、PowerPoint などを更新しに行くように頼む必要はありません。 |
| これはリポジトリに移動するだけです。 |
| そして、JMP とユーザー モードに切り替えて、スクリプトを再度実行します。これにより、新しい PowerPoint が取得されます。 |
| そして、再度実行すると、 |
| スライドを選択すると、スライドが作成されます。 そして、ヘッダー行の色の変更など、変更が加えられていることに気づくでしょう。 |
| それで、 |
| 他に何がありますか？ |
| スクリプトの監視。 これは私たちが開発した最高の機能の 1 つだったと思います。これにより、開発者は、次のことを確認できるようになります。 |
| 彼らの脚本...彼の、彼の脚本は評価されているかどうか。 右。 それで、それは実行されますか？ 誰かが定期的に実行しているのでしょうか？ |
| それが利点の 1 つです。 もう一つの利点は、 |
| ログ...クラッシュログの収集。 したがって、スクリプトが失敗した場合は、JMP のこのログ キャプチャ機能を使用して失敗をキャプチャできます。 したがって、サブルーチンをログ キャプチャに挟み込みます。 |
| 失敗した場合...失敗した場合...失敗のログがこのログ返されたテキストに返されます。 そして、あなたがすることもあなたです |
| これを try で囲み、スクリプトが引き続きレポートを実行できるようにします。 |
| そして、空かどうかを確認します。 空の場合は、クラッシュがまったく発生していないため、スクリプトが生き残ったことを意味します。 |
| しかし、そうでない場合、空でない場合、それはクラッシュが発生し、それを抑制したことを意味します。 ログを取得して、報告できるようになります。 そしてそれを行う方法はHTTPを使用することです |
| ユーザー ID、スクリプト名、ログノート、クラッシュかどうか... |
| クラッシュだったのか、それとも通常の実行だったのか、おそらく何らかのパフォーマンス指標が考えられます。 つまり、スクリプトに関するいくつかのデータ メタデータを開発者に送信できるということです。 |
| そして、サーバーが行うことは、それらをログに記録することです。これにより、一連のファイルがサーバーに保存され、それらを監視できるようになります。 そして、私はサンプルを示しているだけです |
| このうちテーブル。 これはクラッシュ ログで、日付スタンプがあり、スクリプト名が付いているため、このスクリプトはその日付で失敗しました。 |
| 今回の特定のクラッシュでは。 したがって、開発者は戻って問題を修正できるため、これは非常に便利です。 そこで、これとこれを折りたたんで、ここで簡単なデモンストレーションを行い、どのように実行するかを示します。 |
| あなたはどうですか |
| クラッシュの内容と、それをユーザーに報告する方法が含まれます。 ここで私が行うことは、サブルーチンクラッシュを作成することです。 未定義のパラメータを作成します |
| そしてJMPは文句を言うでしょう。 これは定義されていないため、スクリプトがクラッシュしていると表示されます。 しかし、私がやることは、そのサブルーチンを呼び出すことです |
| ログキャプチャ機能では、すべてが under try に挟まれます。 そのため、スクリプトはサブルーチンでクラッシュしましたが、全体としては存続し、エラーを報告できるようになります。 |
| クラッシュレポート。 それで、あなたはそれをユーザーにきちんとフォーマットされた通知を送り、それを言いますか？ そのため、この特定のエラーでスクリプトがクラッシュするため、ログを作成し、現在取り組んでいます。 つまり、それがユーザーに与える通知です。 |
| サミットで私が学んだ重要なことの 1 つは、自動テストについてでした。 そのため、私は以前は手動でテストを行っていましたが、これは非常にイライラさせられます。 |
| 時間がかかり、スクリプトの隅々までキャプチャすることはできないからです。 つまり、小さな変更を行うときに何時間ものテストを行うことは不可能です。 |
| そこで私は自動テストに取り組み始めましたが、単体テストを行うことは非常に重要です。 つまり、テストとは個々のサブルーチンのテストを指します。 関数があり、それをテストしたいとします |
| システム全体に組み込む前に複数回実行することで、これらの単体テストを行うことができます。 |
| 個々のモジュールに対応しますが、それだけでは十分ではありません。 その例をいくつかお見せします。 |
| たとえば、NASA は非常に奇妙なエラーで火星気候探査機を失いました。2 つのソフトウェア チームがあり、1 つはヨーロッパにあったため、非常に奇妙なエラーが原因です。 |
| 1つは米国にあります。そのうちの 1 つはポンドの単位を使用していました、そう、それは米国のものであり、ヨーロッパのものでした |
| ニュートンを使っていました。 したがって、彼らは確かに単体テストを実行しました。 しかし、コードをまとめると、一方はニュートンを期待し、もう一方はポンドを取得していたため、機能しませんでした。 それで彼らは文字通り、 |
| オービター、ポンドからニュートンに変換するのを忘れたからです。 そしてつい最近、スターライナーとして、ボーイング社はスターライナーを紛失し、その後、彼らがそうしていれば間違いを発見できた可能性があることを認めました |
| 厳格な統合テスト。 そして、一日の終わりに重要なのは、 |
| モジュールはスクリプト内で単独で存在するのではなく、一緒に通信するため、統合テストが必要になります。 |
| そして、これはここでの問題の面白い例です。 したがって、2 つのオブジェクトを徹底的にテストすることができます。 それは窓ですよね、窓の何が問題になるのでしょうか？ |
| ただし、それらを 2 つ組み合わせると、開くことさえできないため、それらが結合されているかどうか、一緒に正常に動作するかどうかを確認するためにいくつかの統合テストを実行する必要があります。 |
| ここで、私がどのようにして自動テストを始めたのかを簡単に説明したいと思います。 そして、これは特定のケースを指します。 |
| これはモーダル ウィンドウのテストであり、ボタンをクリックしない限りモーダル ウィンドウは消えないため、公平を期すためにこれは難しいケースです。 だから、そうしなければなりません |
| ボタンをクリックする、人間の動作を模倣するような JMP スクリプトを作成します。ここで私がやっているのは、 |
| ここのモーダルウィンドウ。 このアプローチの良い点は、引き続き配布できることだと思います。 |
| このスクリプトをユーザーに提供しても、ユーザーは実際にテスト ルーチンが含まれていることさえ認識しません。 |
| つまり、テスター用のフックがありますが、これを単独で実行すると、このテスト モード パラメーターが検索されますが、設定されていません。 |
| したがって、設定されていない場合、スクリプトはそれをゼロに設定し、テーブル内のすべてのフックを無効にします。 したがって、これをユーザーに提供すると、ユーザーはこれをこのように実行できます。 |
| ただし、スクリプトをテストしたい場合は、その上にテスター コードを構築します。 したがって、テスター コードはテスト モードを 1 に設定し、テスターも作成します。 |
| スクリプトに挿入するテスター オブジェクト。 たとえば、この特定のケースでは、特定の列を選択しています。 |
| 次に、ボタンをクリックしてロールに割り当て、スクリプトを実行します。 つまり、文字通り人間の行動を模倣していることになります。 |
| したがって、実際のスクリプトがロードされます。 したがって、基本的には、テストするスクリプトにこれらのパラメーターを挿入します。 これで、スクリプトが自動的に実行されるため、スクリプトが読み込まれて実行され、このボタンとそのボタンをクリックすると UI が閉じられます。 |
| そして、ログ キャプチャ機能でそれを再度実行することで、何か問題が発生した場合にその障害をキャプチャすることがわかります。 |
| また、これを enter try に含めると、全体的にスクリプトが存続してログを報告できるようになります。 何も問題がなかった場合は、空のログが返されます。これは、スクリプトが失敗していないことを意味します。 |
| 何か問題が発生した場合は、ログ キャプチャでわかります。 それがアイデアです。 |
| それで、 |
| 我々は持っています |
| スクリプトを監視する機能。 私たちには次の能力があります |
| クラッシュのログをキャプチャします。 そこで私たちは、クラッシュ ログに基づいて行動したらどうだろうかと考えました。 何か問題が発生したことを示すクラッシュ ログが表示され、スクリプトがそのことを示している場合、スクリプトがクラッシュしたことは明らかなので、ユーザーはすでにそれを知っており、開発者は、ログが記録されているためスクリプトがクラッシュしたことを知っています。 |
| サーバーに保存されます。 したがって、彼らはあなたが行動するためにそこにいます。 しかし、問題は、これはまだ閉じたループではないということです。開発者が知っていることをユーザーは知らないからです。 そして、自動チケットを作成することで、そのループを閉じることができます。 すでに情報を持っているので、次のことができます。 |
| JIRA Atlassian などのバグ追跡ソフトウェアを使用すると、REST 機能を使用できるようになります。 |
| サーバーから情報を収集し、チケットを作成して開発者に割り当てます。また、ユーザーをウォッチャーとして割り当てることもできます。 ウォッチャーとは、開発者が何かをするたびに |
| バグについて調べ、その情報を JIRA に入力すると、その情報がユーザーにループバックされるため、ユーザーは通知を受け、誰かがバグに取り組んでいることを知ることができます。 |
| JIRA の好みに応じて、これを行う方法は複数あります。ここでは、次の方法を紹介します。 |
| 基本的なコードはここにあります。 これは作成できるカール コードであり、クラッシュ ログからメタデータを収集し、それを JSL ファイルに埋め込むと、REST 経由で送信され、 |
| JIRA、それは...あなたのためにそれを追跡します。 そして、適切に設定していれば、JIRA が通知します...JIRA は開発者に通知し、場合によっては開発者に通知します。 |
| スクリプトがクラッシュしたユーザー。 そして、これらはすべて結びついており、開発者は自分が取り組む必要があるバグがあることを知り、ユーザーは誰かがそのバグに取り組んでいることを知ることになります。 |
| わかった。 これが私の最後のメモにつながると思います。 このプレゼンテーションから得られるポイントは次のとおりです。 |
| Git は私たちのシステムの基礎であり、Git のおかげで多くの優れた機能が実現できるようになりました。基本的な機能については触れませんでしたが、 |
| これはある意味当然のことです。なぜなら、そうすることでコラボレーションすることもできるからです。 したがって、複数の人が同じスクリプトに取り組んでいる場合です。 のすべての機能を使用できます。 |
