著者:
（１）ジョセフ・ラテッサ、ウェイン州立大学コンピュータサイエンス学部、デトロイトミシガン州、米国（（email protected））
（２）アディ・フリア、セイラム高等学校３年生、ミシガン州カントン、米国（（email protected））
（３）ディーパック・ラジュ、セイラム高校３年生、ミシガン州カントン、米国（（email protected））。
リンク一覧
概要と序論
関連作業
プロジェクトの前提条件
プロジェクトの実施
洞察と考察
結論、謝辞および参考文献
3 プロジェクトの前提条件
これから、プロジェクト開発の各部分を詳しく見ていきます。夏の間、私たちの会議は Zoom を使用して週に 1 ～ 2 回行われ、各セッションは 1 ～ 2 時間続きました。
3.1 ツールとインストール
自己紹介、スケジュールに関する話し合い、そして夏の間に達成したい目標について話し合った後、一貫性のある開発環境を確保するために開発ツールを決定し、インストールしました。これには、WSL インストール プロセスの実行と Ubuntu ユーザー アカウントの設定が含まれます。次に、コマンド ライン アプリケーションとして Windows Terminal をインストールし、優先テキスト エディターとして Visual Studio Code をインストールしました。その後、github.com にアクセスして GitHub の機能を調べ、ユーザー アカウントを設定しました。
3.2 Linux シェルの理解
次のミーティングでは、Windows ターミナルを調べ、ディレクトリ構造をナビゲートするための基本コマンドを入力しました。ls、pwd、cd、mkdir、touch、mv、cp、clear などの基本コマンドについて説明し、実演しました。ディレクトリの作成、ファイルの作成、ファイルの移動、ディレクトリの内容の表示を練習しました。ローカル マシンでのコマンド ラインのナビゲートに加えて、GitHub Actions による自動化には、GitHub のランナーでのコマンド ライン ナビゲーションが必要です。そのため、プロジェクトの後半では、コマンド ラインに精通していることが必要になります。
3.3 バージョン管理の紹介
次の数回のミーティングでは、バージョン管理の学習に重点を置きました。この学習を支援するため、また学生には Python を書いた経験があったため、Python で簡単な計算機アプリケーションを実装しました。メイン関数は、算術演算を選択し、オペランドを入力するためのメニューを提供しました。加算、減算、累乗などの各演算は、必要なオペランドをパラメータとして受け取り、結果を返す個別の関数でした。Python コードのスケルトンが提供され、実装されていない関数スタブはすべてゼロを返しました。
学生たちは、GitHub に新しいリポジトリを作成し、その新しいリポジトリをローカル マシンのディレクトリにクローンする方法を学びました。Git は、GUI ではなくターミナル コマンドを使用して導入されました。これは、GitHub のランナーでコマンドを実行するときに役立つ、コマンド ラインのさらなる練習を提供するためです。リモート リポジトリをクローンする際に、分散型バージョン管理と集中型バージョン管理の概念について説明し、各システムの長所と短所について話し合いました。学生たちは、新しい計算機のスケルトンをリポジトリに追加し、それをリモートにプッシュしました。Git コマンドの clone、pull、status、log、add、commit、push が導入され、適用されました。
このプロジェクトには 2 人の学生が取り組んでいたため、1 人の学生が加算関数を実装し、もう 1 人が減算関数を実装しました。各自がローカルの変更をコミットし、その変更をリモートにプッシュしました。変更を実装している間、各自が画面を共有していましたが、2 番目にプッシュする人は、自分の変更をプッシュする前に、リモートにすでに行われた変更をプルする必要があることに気付きました。また、異なる関数に変更を加えた場合、マージの競合が発生することなく、その違いを自動的に調整できることもわかりました。
次に、ブランチの概念と、特定の機能ブランチで機能を開発する利点について話し合いました。乗算機能と累乗機能を実装するために、別々のブランチを作成しました。1 人の学生が乗算を実装し、もう 1 人が累乗を実装しました。ファイルのステージングとコミットの練習を続け、ローカルの機能ブランチをコミットし、新しいブランチのリモート トラッキングを確立する方法を学びました。また、ステージングされていない変更を最新のローカル コミットと比較したり、関連するコミット ハッシュを使用して他のコミットを比較したりするために、git diff も導入されました。次に、git merge を適用して、機能をローカル メイン ブランチにローカルにマージしました。各学生がコードの異なる部分を変更していたため、マージは自動的に行われ、マージの競合は発生しなかったことが再度確認されました。
次に、マージ競合を作成して実演するために、具体的にコードを編集しました。 両者が同じコードセクションを編集することで、学生はマージ競合を手動で解決する方法を学びました。
バージョン管理の紹介の最後は、プル リクエストとフォークについて見てきました。ブランチをローカルにマージするだけでなく、メイン ブランチへのプッシュ アクセス権を持たない開発者がプル リクエストを送信して変更を提案するという一般的なワークフローについても説明しました。また、リポジトリ フォークの作成についても説明し、プル リクエストをフォーク間で送信する方法も確認しました。最後の計算機関数である平方根関数は、プル リクエストの送信と承認によってメイン ブランチにマージされました。
プロジェクトの次の段階に備えて、学生たちは JETSCAPE (1) と GOMC (2) アプリケーション リポジトリ、および JETSCAPE と GOMC の Web サイト リポジトリの独自のフォークを作成しました。これらのテストの作成に費やされた時間のほとんどは、Web サイト リポジトリに関係するものでした。
3.4 継続的インテグレーションの導入
継続的インテグレーションの概念を紹介するために、requests.get メソッドを使用して Web サイトにクエリを実行し、ステータス コードを返す簡単な Python スクリプトを作成しました。このスクリプトはコマンド ラインで手動で実行でき、コマンド ライン引数として URL を受け入れます。返されたステータス コードが 200 の場合、成功メッセージが出力され、プログラムは通常どおり終了します。別のコードが返された場合、またはサーバーから応答がない場合は、例外が発生してプログラムが終了します。google.com などの人気の Web サイトや、無効であることがわかっている URL で、このプログラムを手動でテストしました。
次に、設定されたスケジュールで、または指定されたブランチに変更があるたびにテストを自動的に実行することの有用性について話し合いました。学生は 2 名で、Web サイトは 2 つ (JETSCAPE (1) と GOMC (2)) であるため、各学生は特定の Web サイトに焦点を当て、ローカルにクローンされたフォークで作業しました。到達可能性をチェックする Python スクリプトをコミットし、自動化を生成するために必要な YAML ファイルの手順について話し合いました。テストは、メイン ブランチへのプッシュ操作とプル リクエストで実行し、1 日に 1 回特定の時間に実行することに決定しました。ubuntu-latest での実行、GitHub のチェックアウト アクションを使用した現在のリポジトリのチェックアウト、GitHub のランナーでのターミナル コマンドの実行 (pip を使用) などのジョブ手順について話し合いました。各ジョブは ubuntu-latest の新しいインスタンスで実行されるため、この手順はワークフローが実行されるたびに実行されることを話し合いました。次に、ランナーの tests/ フォルダーに移動し、URL 到達可能性スクリプトを呼び出す python3 コマンドを実行するジョブ手順を追加しました。 学生たちはコミットし、リモートフォークにプッシュし、GitHub の[アクション]タブをチェックして、実行中のテストとそれぞれのログを確認しました。
学生たちは、Python 言語に関する事前の知識を身に付け、コマンドライン、バージョン管理、GitHub Actions を使用したワークフローの自動化に精通したため、自動テストの作成と展開に関する調査と実験を開始する準備が整いました。