アクセスソースコード管理にOASIS-SVNとgitを使用する

注： このトピックについては、7月9日午後6時30分CDTに開催されるAccessおよびSQLServerの月例ウェビナーで詳しく説明します。プロセスをライブで表示して質問できるように登録してください！

複数のアプリケーションを使用し、チームで作業する場合もあるため、変更を管理するにはソースコードの制御が非常に重要です。プロジェクトにgitを使用するのが大好きになりました。元々、Accessでgitを使用するのは困難でしたが、OASIS-SVNという名前のアドインのおかげで、変更を管理するためにAccessプロジェクトでgitを効果的に使用できます。

なぜソースコード制御を使用するのですか？ただ圧縮することはできませんか？

ソースコード制御の背後にある主な目標は、フーダニットに簡単に答えられるようにすることです。

これは、バグレポートを処理しているときに特に重要であり、以前に同様の何かを見たことがあることを思い出し、おそらくそれを修正したと思ったが、顧客はまだそれを報告しています。ただし、バグが6か月前に「修正」された場合、6か月前に行った修正をすでに忘れているため、まったく新しいバグである可能性もあります。あなたのことはわかりませんが、大量の圧縮されたバックアップを掘り下げる可能性はあまりありません…発見可能です。

変更をソースコードコントロールに入れるには規律が必要ですが、変更の確認と管理がはるかに簡単になります。履歴を簡単に検索して、正確に何が変わったかを確認できます。

別のシナリオは、正確に何が変わったかを把握することです。いくつかの変更を加えて、新しいバージョンをプッシュする前にそれらを確認する必要がある場合は、ソースコードコントロールが役立ちます。あなたは自分の仕事をチェックし、あなたがやろうとしていることをすべてやったことを確認する機会があります。もう「私はすでにそれをしたと思います。」クライアントから言われたのは、先週クライアントがあなたに尋ねた細かいことを忘れてしまったことだけです。さらに、これにより、チームは他の人のコードレビューを行うことができます。他の人の仕事を見てフィードバックを提供し、お互いが高水準の品質を維持できるように支援することができます。

なぜgitなのか？ AccessはVisualSourceSafeで動作しますか？

Access 2013より前のバージョンでは、Accessはソースコード制御をネイティブにサポートしていましたが、独自のMicrosoft仕様であるMSSCCIを使用していました。さらに悪いことに、この仕様では、開発者が作業中のオブジェクトを排他的にロックできるチェックアウト/チェックインモデルを想定しています。さらに、Accessアプリケーション内のテーブルは、基本的に1つの大きなブロブであり、レビューはもちろんのこと、読み取ることもできませんでした。

実際には、このようなモデルは、小さなチーム設定でも使用するのが非常に面倒です。主な問題の1つは、変更要求が1つのオブジェクトに対してのみ確認されることはめったにないことです。開発者は、少数のオブジェクト以上に触れる必要があることに気付く場合があります。そのため、特にコア/共有モジュールの場合、衝突は避けられない可能性があります。

Gitは、古いチェックアウト/チェックインモデルで見られるすべての醜さを回避しますが、これには変更の管理に異なる哲学が必要です。何かをチェックアウトする代わりに、ブランチを処理し、それが終わったら、メインブランチにマージします。必要に応じて、複数のブランチを並列に配置できますが、実際には、2つまたは3つの並列ブランチのみが必要です。 1つは製品版を表します。他は開発用で、おそらく3分の1は重大なバグ修正用です。これはAccessプロジェクトで実行でき、実行する必要があります。そうしないと、特に重要なアプリケーションの場合、本番ファイルに何が入っているかを追跡することが非常に困難になる可能性があります。

gitを学習するための優れたリソースはここにあります。サンドボックスがあるので、一緒に遊ぶことができます。あなたが私のようで、肉付きの良いものを切り詰めて、それがどのように機能するかを知りたいのであれば、これは良いリソースです。

最後に、VisualSourceSafeの使用をすでに停止します。バグがあり、データが失われる傾向があり、2013年以降Accessでもサポートされていないため、_年間_サポートされていません。

しかし、Access 2013+がソースコード制御をサポートしなくなった場合、どうすればそれを維持できるでしょうか？！？

OASIS-SVNはMSSCCIプロバイダーではなく、単なるAccessアドインであるためです。制限を回避する他の同様のAccessアドイン（たとえば、Ivercy）があります。いずれの場合も、これらのアドインは、Accessがソースコード制御に内部的に使用したものとまったく同じ文書化されていないメソッドを多用します。 Application.SaveAsText およびApplication.LoadFromText 。これらのメソッドは、Accessの現在のバージョンに引き続き存在します。余談ですが、継続性を確保するためにそれを文書化するためのUVアイテムがあります。 OASIS-SVNは、現在のAccessバージョンでも引き続き正常に機能します。

なぜOASIS-SVNとgitについて話し続けるのですか？どちらか一方だけを使用できますか？

両方のツールは補完的であり、両方が必要であることを理解することが重要です。ほら、OASIS-SVNが必要な理由は、バイナリファイルの大きなブロブの中にそれらを置くのではなく、ハードワークを取り出してテキストファイルの束として表現するのをできるだけ簡単にするためです。 ACCD*ファイル。 ACCDBファイルをソースコードで制御することは意味がありません。これは、ACCDBファイルに適切な変更履歴がなく、ほとんど読み取れないためです。したがって、OASIS-SVNは、Accessアプリケーションの再構築に使用できるテキストファイルを作成するためのツールであり、これらのファイルを実際にソースコード化するのはgitの仕事です。 gitはACCDBファイルでは機能できず、機能しないはずです。

gitを初めて使用する場合は、面白い拡張子を持つテキストファイルの束を含む実際のフォルダーのセットではなく、バイナリファイルを使用しているため、他のユーザーがVisualStudioプロジェクトで通常行うことと比較して追加の手順があります。そのため、ACCDBファイルとgitリポジトリを構成するテキストファイルの間で変更を一貫してエクスポート/インポートする習慣を身に付ける必要があります。

前提条件

開始するには、3つのソフトウェアが必要です：

1. Git For Windows
2. TortoiseGit
3. OASIS-SVN

厳密に言えば、2番目と3番目のソフトウェアは必要ありません。実際には最初のものだけで済ませることができますが、大きな欠点は、これを行うために独自のVBAモジュールを作成して手動でエクスポート/インポートする必要があることです。これは、次のように明確になる理由から、多くの作業です。従います。したがって、OASIS-SVNを強くお勧めします。 TortoiseGitも必要ありませんが、作業を簡単にするためのGUIが本当に気に入っています。これは、かなりのGUIを介さずに、コマンドラインでgitを使用する必要があると言うコマンドラインの純粋主義者を怒らせる可能性があります。ただし、私はそれが怠惰で迅速であることが好きで、ほとんどの場合、プロセスは単純で、bashシェルを開いてコマンドを入力するよりも、メニューからコマンドを実行する方が速いです。とは言うものの、TortoiseGitは実際にはgitコマンドの単なる薄いラッパーであるため、実行されるgitコマンドとその意味に細心の注意を払う必要があります。

それらをすべてインストールします。詳細な手順については、それぞれのWebサイトを参照してください。これがすべて設定されたら、制御したいプロジェクトを用意する必要があります。さらに、アップストリームリポジトリとして機能する場所が必要です。たぶん、Azure DevOpsアカウントをお持ちですか？ Bitbucket？ GitHub？ソースコードコントロールをホストするために利用できるいくつかのオプションがあります。気が向いたら、プライベートgitサーバーをセットアップすることもできます。しかし、それも記事の範囲外です。繰り返しになりますが、空のリポジトリを設定するには、それぞれのプロバイダーのドキュメントを参照してください。

空のリポジトリを作成したら、そのリポジトリへのリンクを提供する必要があります。 Auzre DevOpsを使用し、次のURLに新しいリポジトリを作成しました：
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
これで、空のリポジトリへのリンクができたので、セットアップを開始できます。

ローカルリポジトリの作成

OASIS-SVNにはウィザードがありますが、既存のリポジトリのクローンを作成してそこから作業する方が簡単だと思います。同様のことを行うウィザードを自由に使用できますが、手動の方法に従うと、実際に何が起こっているのかを理解し、ツールの操作が簡単になると思います。特定のフォルダにアプリケーションがあると仮定します：

Sourceフォルダーは空であり、ローカルリポジトリのテキストファイルを格納する場所になります。フォルダ内の空白を右クリックして、 TortoiseGitを開くことができます コンテキストメニューからクローンリポジトリを選択します。

開いたダイアログで、ホスティングプロバイダーから取得したURLを入力します：

注意

次に、リポジトリのクローンが作成されたことを示す成功ダイアログが表示されます。

クローン作成の効果として、 .gitという名前の隠しフォルダーが作成されます。 。これが、gitがローカルリポジトリのコミットと変更を追跡する方法です。

これで、Accessからのテキストファイルを保持するために使用できるローカルリポジトリが機能するようになりました。これを利用するには、OASIS-SVNを構成する必要があります。

OASIS-SVNの設定

前述のように、OASIS-SVNにはセットアップに使用できるウィザードがありますが、OASIS-SVNの動作に精通しているため、ウィザードを効果的に使用できるように、手動でこれを実行する必要があります。まず、設定に移動します OASIS-SVNリボンタブのメニュー。

これにより、ダイアログが開きます。今のところ、必要なことは1つだけです。ソースパスを設定します。一般に、絶対パスよりも相対パスを使用する方が便利だと思うので、 \ Sourceに入れます。 図のように：

入力したら、チェックボックスをオンにする必要があります常にを使用 ：

これにより、リポジトリフォルダが相対的になり、プロジェクトフォルダを任意の場所に移動できるようになります。ただし、注意してください。Accessファイルをそのフォルダーの外にコピーまたは移動した場合、OASIS-SVNには .oasis がないため、ソースコード管理下に置くことはできません。 OASIS-SVNが必要とするファイル。 [OK]をクリックしてダイアログを閉じ、設定への変更を保存します。フォルダを見ると、 .oasisが表示されます。 ACCDBファイルのファイル。

.oasis fileは、すべてのプロジェクト設定を含む単なるXMLファイルであり、このACCDBファイルがソースコード管理下にあることをOASIS-SVNが認識できるように、ACCDBファイルと同じ名前である必要があります。したがって、ACCDBファイルの名前を変更する習慣がある場合は、その習慣を破る必要があります。既存のワークフローにファイルの名前変更が含まれる場合、私が便利だと思う1つのアプローチは、開発コピーに固定名を使用することです（例： SampleApplication Dev.accdb 、おそらく）、名前を変更する必要がある場合は、そのファイルのコピーを作成し、適切な名前を指定します。ソースコードコントロールでそれを使用すると、バージョンを追跡する手段として名前を変更することは、異なる名前のコピーをたくさん持つのではなく、git履歴から再作成できるはずなので、今ではあまり意味がないことを強調する必要があります。

残りの設定の構成

前の手順では、 .oasis がなかったため、ソースファイルのみを設定しました。 ファイル;他の変更を加えた場合、保存されていない可能性がありますが、プロジェクトフォルダーを設定した結果、作成されたので、残りの設定を確認できます。テンプレート.oasisを検討することをお勧めします。 ファイルを作成して、すばやくコピーして手作業で微調整し、さまざまなAccessプロジェクトのプロジェクト設定を統一できます。 設定に戻りましょう リボンのボタンをクリックして、ダイアログの最初のタブから始めます。

オブジェクトタイプペイン

ADPを使用しなくなり、廃止されたデータアクセスページを使用しないため、通常、インポート/エクスポートダイアログの煩雑さを最小限に抑えるためにADPのチェックを外します。また、自動変更を自動選択することも便利です。これには、オブジェクトのタイムスタンプを追跡する必要があります。ただし、オブジェクトのタイムスタンプはAccess内で完全に信頼できるわけではないことに注意してください。これについては、後のセクションで詳しく説明します。とはいえ、迷子のオブジェクトをコミットするのを忘れたかどうかを指摘するのに役立つ良い方法です。

テーブルオプションペイン

このペインには注意深い検討が必要であり、扱っているプロジェクトのタイプによって異なります。一番のルールは、テーブル内のデータをソースコードで制御したくないということです。データはコードではないので、それは意味がありません。ただし、それは必ずしも厳密には当てはまりません。たとえば、アプリケーション構成データとして使用するテーブルがいくつかあります。したがって、ある意味で、これらのテーブルは、アプリケーションの動作に影響を与えるため、「コード」です。プロジェクトの大部分はSQLServerバックエンドを備えたAccessフロントエンドであるため、通常存在するテーブルは主に構成テーブルであり、ソースコードの制御に適しています。ただし、データテーブルがある場合は、それらを含めるべきではありません。ここで高度な ボタンが便利です。これをクリックすると、このダイアログが開きます：

すべてのテーブルのデータをエクスポートのチェックを外します 下部のチェックボックスをオンにすると、ソースコードの管理下に置くテーブルのデータを選択できます。ただし、データテーブルであり、アプリケーションのソースコードの一部ではないものは除きます。

また、通常、テーブルを再リンクするコードルーチンがあるため、ODBCリンクテーブルは通常含まれていません。そのため、ソースコードコントロールにそれを含めることは意味がありません。ただし、アプリケーション構成テーブル、またはローカルテーブルの定義だけを用意することをお勧めします。これらのテーブルの定義なしで、gitリポジトリからファイルを作成すると、アプリケーションが壊れてしまうからです。

設定ペイン

.oasis を作成したときに、これはすでに見ました。 ファイル。ファイルができたので、残りの設定をセットアップします。これが私たちの典型的なセットアップです。

冒頭で述べたように、独自のインポート/エクスポートルーチンを作成できると考えられます。ただし、OASIS-SVNの価値は、Accessテキストファイルをソースコードの下に保持することで存在するさまざまな問題に対処できることです。たとえば、Accessテキストファイルのファイルの上部に一般的なフィールドがある場合があります。
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
これらは、不要な変更を導入し、実際には変更ではない変更の履歴を汚染する可能性があるため、ソースコードの制御には適していません。フォーム自体について実際に何も変更していない場合でも、チェックサムは変更される可能性があります。 OASIS-SVNでは、オプションエクスポートされたファイルのサニタイズを使用して、不要なデータを取り除くことができます。 ：
Version =21
VersionRequired =20
Begin Form
...
End Form
レポートの黄色の警告アイコンに気付いたかもしれません。それが存在する理由は、OASIS-SVNが、ソースコード管理に悪名高いプリンタデータも削除するためです。レポートがデフォルトのプリンタを使用している場合、通常は問題ありません。ただし、特定のプリンターに依存するレポートを作成することは珍しくありません。たとえば、専用プリンターでバーコードラベルを作成しているレポートがあるかもしれません。そのレポートでは、デフォルトのプリンタではなく、特定のプリンタを選択します。レポートのチェックボックスをオンにすると、プリンタデータが吹き飛ばされます。プロジェクトが特定のプリンタ設定に依存していない場合は、レポートを確認する方が簡単な場合があります。それ以外の場合は、フォームをチェックしない理由はありません。

同様の理由で、分割フォームファイルが大好きです。 および分割レポートファイル オプションがチェックされています。通常、 Application.SaveAsText 単一のAccessオブジェクトの単一のテキストファイルをエクスポートします。ただし、テキストファイルを読んだ場合は、レイアウトコードを読むのが面倒であることがわかります。このオプションをチェックすると、Accessオブジェクトごとに2つのテキストファイルを取得できます。 1つはすべてのレイアウトデータを含み、もう1つはフォームの背後にある実際のVBAソースコードです。これにより、VBAの変更に焦点を合わせて何が変更されたかを理解できるため、コードレビューがはるかに簡単になり、レイアウトの変更が何であるかを簡単に理解できるようになります。

オブジェクトタイプに関する前のセクションから思い出してください。 ペインで、変更を選択しました。これには、オブジェクトの日付/時刻をファイルの日付/時刻として保存する必要があります。それはここでもチェックされています。オブジェクトを変更するときに、Accessが常にタイムスタンプに確実にスタンプを付けるとは限らないことに注意してください。これについては、コミットの作成に関する後のセクションで再度説明します。

統合ペイン

通常、オートコレクトが常にオフになっていることを確認したいのですが、より重要なのは、エクスポートを行うためのホーキーとしてCtrl+Sを使用するオプションです。これは非常に役立ち、Accessオブジェクトのタイムスタンプの問題を回避します。ただし、これには、キーボードショートカットを一貫して使用して変更を保存するための規律が必要です。キーボードを実行するたびに、次のダイアログが簡単に表示されます。

これにより、変更を処理するときに、gitの作業ツリーが作業中のACCDBファイルと同期していることが保証されます。頻繁に保​​存することを恥ずかしがる必要はないことを強調することが重要です。すべての保存をコミットする必要があるという意味ではありませんが、頻繁に保存することで、作業ツリーは変更の範囲を正確に反映します。コミットする準備ができています。これについては、後のセクションで詳しく説明します。

インポート前の自動更新 およびエクスポート後の自動コミット 便利なことのように思えるかもしれませんが、実際には、これを手動で行う方がはるかに望ましいことがわかりました。特に、Ctrl + Sショートカットを使用してエクスポートする場合は、必ずしもコミットする必要がないためです。進行中の作業のみを保存して、実際にコミットする準備ができたときに何が変更されたかを確認できるようにします。そのため、それらは省略します。

.oasis 設定ファイル

設定ダイアログで[OK]をクリックすると、さまざまなペインで行った変更が .oasisに書き込まれます。 XML形式のファイル。前述のように、それをコピーしてテンプレートを作成すると、別のAccessアプリケーションをすばやく構成できます。これで、実際のソースコード制御を行う準備が整いました。

エクスポートとコミット

すでに述べたように、バイナリファイルを使用しているため、ソースコード管理で適切に管理できるように、すべてをテキスト表現にエクスポートする必要があります。これを行うには、オブジェクトをエクスポートする必要があります。示されているように、OASIS-SVNエクスポートボタンを使用できます。

エクスポート用にリストされたすべてのオブジェクトタイプを含むダイアログが表示されます。これが最初のエクスポートであるため、 Ctrl + Aを使用します エクスポートするすべてを選択します。

[OK]をクリックしてエクスポートを終了します。すべてがうまくいけば、そのことを示すメッセージが表示されます。

ソースフォルダ内を見ると、エクスポートしたばかりのさまざまなオブジェクトを表すすべてのテキストファイルが表示されます。前のセクションで示したように、[設定]ペインで選択した内容によって、命名規則が異なる場合があることに注意してください。また、ファイルを分割することを選択したため、両方の .def があります および.layout 単一のAccessオブジェクトのファイル。

オブジェクトがテキストファイルとしてエクスポートされたら、変更をコミットする必要があります。 OASIS-SVNは、示されているようにAccess内から直接TortoiseGitコマンドを提供します。

通常、使用する4つのコマンドをここに示します。他のコマンドは使用に適していますが、より複雑なgitシナリオにたどり着くまで、それについて心配する必要はありません。ちなみに、これらのコマンドは実際には、Windowsエクスプローラーのコンテキストメニューを介してTortoiseGitによって公開されるコマンドと同じです：

さらに、コマンドのサブセットは、アクセスナビゲーションペインの右クリックメニューから利用できます。

したがって、OASIS-SVNまたはTortoiseGitをAccessから直接使用して作業を実行する方法はいくつかあります。または、Windowsエクスプローラーから直接TortotiseGitを使用することもできます。 コミットがあることに注意してください すべてのスクリーンショットで;これが次のステップになります。これを選択すると、TortoiseGitダイアログが開きます：

通常、すべてを選択する必要があります。プロジェクトフォルダに置いたテキストファイルのみを追跡することに注意してください。その点は強調する価値があります。 Accessからオブジェクトをエクスポートしなかった場合、gitはそのオブジェクトを認識できない可能性があります。説明的なコミットメッセージを提供する必要があります。詳細な方が良い。また、履歴を理解しやすくするために、いくつかの小さなコミットを実行することをお勧めします。 1000回の変更で週に1回コミットする必要はありません。それを理解するのは不可能でしょう。タスク（特定のバグの修正や機能の導入など）の完了後にコミットして、履歴を理解しやすくする必要があります。

作業をコミットする習慣を身に付けたら、TortoiseGitにはコミットするための3つのオプションがあることに注意してください。

再コミット 2つ以上のタスクを実行し、タスクごとにコミットを分離したいために複数のコミットを行う必要がある場合に便利です。タスクを完了したらすぐにそれを実行してコミットする必要はないかもしれませんが、興奮に巻き込まれた場合は、コミットするファイルのサブセットのみをチェックして、[再コミット]をクリックするだけです。 TortoiseGitはそれらのサブセットファイルのみをコミットし、コミットダイアログをリセットして、別のメッセージでファイルの他のサブセットをコミットできるようにします。

コミットとプッシュ コミットとプッシュを組み合わせるためによく使用されます。コミットはローカルのgitリポジトリにのみ書き込むことを覚えておくことが重要です。しかし、私たちはリモートリポジトリを持つことから始めました。ローカルコミットをサーバーにプッシュするまで、コードの変更を同僚と共有したり、作業のリモートバックアップを作成したりすることはできません。これがプッシュの目的です。これについては後で詳しく説明します。

コミットすると、TortoiseGitは進行状況ダイアログを提供し、成功した場合は通知します。

まとめ

これまで、gitリポジトリを設定し、OASISを構成して、最初のコミットを行う方法を学びました。しかし、それは表面をかろうじて引っ掻いているだけです。分岐し、履歴を読み、競合を解決するまで、gitの完全な機能はまだ明らかではありません。ただし、これらは厳密にgitのものであり、AccessまたはOASISとはあまり関係がありません。記事の冒頭ですでにリンクしている一般的なgitガイドは、gitリポジトリの管理方法を理解するのに非常に役立ちます。 TortoiseGitはgitコマンドの単なる薄いGUIラッパーであるため、チュートリアルでbashシェルの使用について説明している場合でも、同じ名前のTortoiseGitメニューを使用して同じことを実行できるはずです。質問がありますか？コメントで質問してください！