web-dev-qa-db-ja.com

SCMなしでコードの品質を維持するにはどうすればよいですか?

私は政府機関で働いています。ここで使用されているテクノロジーとソフトウェアを開発する方法はかなり古いものです。

大量のストレージスペースがありますが、ここでのほとんどの作業を自動化するために使用されるアプリケーションを維持および維持するための適切なスペースがありません。

この機関では、GITやSVNなどのSCMソフトウェアを使用できません。

コードの品質を維持し、後でアプリに新しい機能を追加できるようにするための最良のアプローチは何でしょうか?

コードを壊すことなく、コードに加えた変更をどのようにして記憶できますか?

編集:私は言及するのを忘れていました、彼らは各コンピュータ用のネットワークドライブを持っています、そしてどういうわけかこれらのネットワークドライブは定期的にバックアップを作成または保存します。ただし、自分の作業を保存し、既存のコードを壊すことなく新しい機能を追加できるようにする独自の計画を作成しない場合、SCMソリューションに勝る大きな利点はありません。

編集:多くの人々がポータブルGitを提案したので、もっと情報を追加する必要があります。 Visual SVNサーバーをインストールしようとしましたが、インストールする管理者権限がないため失敗しました。通常のGit Shellもダウンロードしてみましたが、ファイアウォールまたはネットワーク設定でGitダウンロードページにアクセスできませんでした。私も、Gmailである私のメールにポータブルGitを送信してみました。 Googleはパッケージ内のexeファイルを検出しましたが、それでも、仕事用のコンピューターにポータブルGitバージョンをダウンロードできませんでした。私が言及しなければならないもう1つのことは、教育機関を通じてコン​​ピューターに適用されるネットワークポリシーは、USBストレージデバイスの使用を許可していません。 USBポートを使用して、スマートフォンを充電したり、小型スピーカーなどのガジェットに電力を供給したりできます。また、一部の人々が述べたように、インターネットでさえも許可されていないコンピュータがあります。

112
Vlad

3つのシンプルなツールを使用して、ソース管理が果たす役割を大まかに複製できます。

  • バックアップソフトウェア(コミット/チェックイン)
  • フォルダー(ブランチ)
  • KDiff3(ブランチのマージ)などのツールを使用して2つのディレクトリ間でディレクトリマージを実行する

基本的に、ワークフローは次のようになります。

  1. 新しいフォルダー(新しいブランチ)を作成する
  2. 既存のフォルダー(既存のブランチ)から新しいフォルダー(新しいブランチ)にファイルをコピーする
  3. そのフォルダーのバックアップを作成します(新しいブランチの作成を終了します)。
  4. いくつかの作業を行います
  5. 新しいフォルダのバックアップを作成(コミット)
  6. あるフォルダから別のフォルダにディレクトリをマージします(マージ)
  7. 他のフォルダで別のバックアップを実行(マージをコミット)

SVNやTFSのような、よりモノリシックなソース管理システムは、基本的に、舞台裏でこれを行います。


現実は、これはバス会社がドライバーにバッテリーのあるバスを運転できないと伝え、ドライバーにバスを坂を押し下げ、クラッチをポップしてバスを始動させるようなものです...これはひどい現在の経営陣はバスガレージの運営について何も知らないことを示しています。お悔やみ申し上げます。

しかし、少なくともあなたはバスを始めることができます。

176
Greg Burghardt

コンセンサスは確かにこの会社では機能しないとは思いますが、それが本当にあなたの質問に答えるとは思いません。

SCMを実際に置き換えることはできません。

あなたは本格的なシステムの通常のベルとホイッスルを必要としないかもしれません。たとえば、会社はサーバーの要求を拒否しても、ローカルSCMの使用を許可する場合があります。彼らはgitが嫌いかもしれませんが、Subversion(または他のバージョン管理システム)を許可しています。

もちろん問題があります。あなたの同僚は何を使っていますか、または以前の労働者は何ですか?あなたが彼らが持っている最初のソフトウェア開発者であるなら、それはあなたが必要とするリソースのために非常に強く押すあなたの時間です。

結局、会社が自分の役割と経験を尊重せず、必要なツールを許可しない場合、ソース管理の欠如よりもさらに深刻な(そしてストレスの多い)問題が発生することになります。

139
Erdrik Ironrose

基本的に、管理上の問題(組織が ソフトウェア開発プロセスの基本を理解していない 、たとえば Vモデル )が、現在の最小限のワークフロー、方法論、とツール。これは一般的です( ピーターの原理 について読んでください)。

ところで、2017年末のパリでの最近の SNCF鉄道インシデント にも同様の原因があると思います(高度な管理レベルでのソフトウェア文化の完全な欠如、したがって、パリの主要な鉄道駅の1日以上の閉塞;もちろんSNCFには非常に有能なITチームがいますが、彼らは主要な決定について相談を受けていません。ソフトウェア文化がまったくないヨーロッパのいくつかの産業を挙げれば、アメリカでも同様のことが見つかるはずです。

主な問題は次のとおりです:コードベースで一人で作業していますか、それとも同僚と作業していますか?

単独で作業している場合は、コンピューターのローカルで git を使用して、コード(およびおそらく.gitリポジトリ)定期的に(その外部ストレージスペースに)。半日以上の作業を決して失わないようにしてください(したがって、定期的かつ確実にデータをバックアップしてください)。

(私はあなたが少なくともgitsvnの両方を知っていて、gitの技術的優位性を知っていると思います。職場のコンピューターにgitのようなツールをインストールすることさえ許可されていない場合、そのことについて上司と真剣に話し合う必要があります問題:外部のオープンソースツールをインストールする機能と承認が必要です(そして、それは、責任に応じて、適切に選択、構成、およびインストールする&に注意してください既知の 脆弱性なし

複数の同僚と作業している場合(おそらく12人未満と思います)、バージョン管理システムを使用するには全員を納得させる必要があります。おそらく、それについてあなたの直接の(そして一般的な)上司に。彼は(おそらく)いくつかのマシン(おそらく古いデスクトップでさえ、おそらくあなた自身のデスクトップでさえ)がgitサーバーとして使用されていることを(おそらく)暗黙のうちに受け入れるかもしれません。そのサーバーをセットアップして、gitリポジトリが少なくとも1時間ごとにバックアップされるようにする必要があります。チームの1時間以上の作業を失うことはできません(上司に相談する必要があります)。

ところで、私はLinuxが大好きなので、gitサーバーとして機能するマシンにLinuxをインストールすることをお勧めします。次に、gitのインストールと定期的なバックアップの構成(crontabジョブを使用)はvery簡単です。 gitサーバーは、それを使用するWindowsクライアントでLinuxを実行できることに注意してください。可能であれば、開発マシンをLinuxに切り替えることをお勧めします。それは「より安価」であり、はるかに開発者に優しい

ただし、SCMを使用する必要があります。あなたは上司に別の質問をするかもしれません:チームは既存SCMを使用するべきですか、それとも車輪を再発明して独自のSCMを作るべきですか?ボスは一般的に、車輪を再発明するという考えに反対しています。ホイールの再発明が許可されている場合は、少なくとも1年間はフルタイムで仕事をしていることを上司に伝え(おそらく上司が泣くようになり、明白な方法を受け入れることになります)、自分のSCMを作るのを楽しんでください。そのようなまれなケースでは、必ず既存のSCMシステムを調べ、SCMシステムをいくつかのフリーソフトウェアツール(他のチームが使用および改善するため)にするように依頼してください。

準備する必要がある場合があります(数日間)a精密SCMの必要性に関する特定の引数:最初は同僚、次に直属の上司。具体的な解決策も提案するようにしてください(一部のgitサーバーをデスクトップまたは「古い」サーバーで実行し、crontabジョブを介して1時間ごとにバックアップするなど)

ソフトウェアをインストールしないでください(外部から、オープンソースでも)無許可で仕事用コンピュータに(ほとんどの国、特に国の機密IT作業では、許可なしにソフトウェアをインストールすることは法的に犯罪であり、そうする場合、あなたは職を失うか、刑務所に行く可能性があります....そうすることを許可されていることを確認してください;おそらく書面で、または少なくとも電子メールで許可を求めることによってあなたのお尻をカバーします)。

(ケースバイケースで質問する必要があります。または、合法的なソフトウェアのインストールを許可するには、組織から信頼を得る必要があります。ソフトウェア-仕事用コンピューター)。

PS。 技術的にビルド、設定、インストールしてgit(またはそのフリーソフトウェアのソースコードから)を使用する方法-または他のほとんどのフリーソフトウェアVCS-マシン上(管理者権限なしでも)非常に異なる質問(他の場所で質問されます)。また、十分なリソース(時間、ディスク容量、一部のCコンパイラなど)があれば、管理者権限なしでgitをインストールして使用できます。

Visual SVNサーバーをインストールしようとしましたが、インストールする管理者権限がないため失敗しました。

これは、 フリーソフトウェアgitまたはSubversionのソースコード- バイナリパッケージだけでなく(および/-ソースコード / 依存関係 からのsvnまたはgitの特定の構成およびコンパイルによって解決できます- /);技術的にそれを行う方法は異なる質問です(ただし、そのような技術的な質問はの場所で行う必要があります)。もちろん、それを行う前に、gitのソースコードをコンパイルする許可を(上司に)尋ねる必要があります。彼は、そのソースコードを外部から仕事用コンピューターに転送することに関する実際の詳細(彼がそのような解決策を受け入れる場合)についてあなたに説明するか、または彼と話し合います。

25

私が最初に行うことは、政府機関(おそらくIT部門)が反対していることを具体的に識別することです。ストレージスペースはあるがサーバー用のVMをホストする方法がない場合、問題はIT部門がSVNまたはGIT serverにノーと言っていることであり、それは大きな違いです。問題が発生国である場合、つまり私たちは外国のエンティティによって作成されたツールを信頼していません-それは別の問題です。

GITはファイルシステム内で完全に実行できます。これは、私が幼児プロジェクトで何かをする準備ができる前に行ったものです。 GITのインストールにも管理者権限は必要ありません。

何らかの理由でGitを絶対に使用できない場合は、いくつかのオプションを利用できます。

  • 教育:バージョン管理を許可しないことにより、重大なリスクが生じます。より問題があることが判明した変更を取り消す機能が必要です。あなたは政府のお金と時間を節約する能力を必要としています、そしてSCMはそれをします。方法を明確に説明できる必要があります。また、ポイントを実際に理解するために、代替案の分析を行う必要もあります。
    • 1つの代替案はGitでホストされます
    • 別のファイルシステムGit
    • 少なくとも1つ、ただし2つ以下の代替SCMツールを選択してください
    • そして最後に、バージョン管理なしで動作するようになっているもの
  • 70年代の時代の発展:patchdiffがずっと前(80年代)に作成されたのには理由があります。それらはバージョン管理を可能にした実現技術でした。

70年代の発展はどのようなものですか?それはきれいではありませんが、それが私たちが始めた方法です。アプリケーションははるかに小さかった。基本的に、彼らにはいくつかの共通点がありました:

  • ゴールドスタンダードの概念がありました。これは完全な機能を備えたマスターソースコードでした。
  • 構成管理(CM)チームがありました。彼らの責任は、開発からゴールドスタンダードに正しく変更を加えることでした。これは、チームの代わりにpatchおよびdiffが必要な場所です。
  • ソースコードのローカルコピーから作業しました。機能全体を完成させ、CMチームに送信して統合してもらいます。通常、新しいドキュメントが作成されたり、古いファイルが削除されたりするように、添付文書があります。
  • 次に、統合プロセスからのエラーを修正します。
  • 別の機能やバグ修正を楽しむ前に、ゴールドスタンダードの新しいコピーを入手します。

基本的に、これはエラーが発生しやすいプロセスであり、問​​題が発生する可能性が高くなります。 「ブランチング」のアイデアは実装が簡単ですが、管理するのは悪夢です。主な問題は、ソースコードのコピーが多すぎる場合、本番環境の正しいベースラインが何であるかを理解することが難しいことです。実用性のために、あなたはシングルスレッドになる必要があります。

これは、代替案の分析に含める必要があるものです。

11
Berin Loritsch

コメントで言及した制約を考えると(例:Gitダウンロードページ、Windowsプラットフォームにアクセスできず、Visual Studio 2005を使用して)、2つのオプションが表示されます。どちらも以前に同じような状況で使用したものです。

  1. Emersonがコメントで示唆するように、 Visual SourceSafe を使用します。私は数年前にVS 2005を使用しているチームと協力しましたが、会社の残りのほとんどはLinux/Unixで標準バージョン管理を使用しており、彼らは喜んでCMにVisual SourceSafeを使用しました。現時点ではかなり古風ですが、何もないよりはましです。
  2. 何もないよりはましと言えば、私も自分自身と同じような束縛を経験しています。 VSSを使用することさえできない場合(プラグインがインストールされていない可能性がありますか?)、利用可能なストレージスペースが十分にあると言うので、うまくいけば、その一部を使用できます。手動のファイルベースのバージョン管理プロトコルを実装しました。毎日の仕事の終わりに、コードベースを新しい日付がスタンプされたディレクトリにコピーします。以前の作業を参照する(またはロールバックする)必要がある場合は、以前の日付のディレクトリを調べて、必要な変更を見つけます。 Visual Studioを利用できるので、数時間以内に、VS 2005を使用して、ディレクトリの作成とファイルのコピーを自動化するのに役立つ簡単なツールを作成できます。
9
Ogre Psalm33

たくさんの収納スペースがあります

決定時にそれを使用することは許可されていますか?

もしそうなら、あなたはfile systemリモートリポジトリを作成することができます。欠点は、gitがリポジトリ全体をダウンロードして変更を探す必要があるため、プロジェクトの成長中にプッシュが遅くなることです...

これまでのところ、コンピュータは通常のユーザーのように動作しており、サードパーティのソフトウェアをインストールすることはできません。

gitportable appとしても提供されるため、$ HOMEまたは%USERPROFILE%パスにインストールできます。


結論として:SCMの使用を禁止しないでください。1。 「プライベート」で使用します。結局のところ、どこかでチェックインされているかどうかにかかわらず、コードが開発されたかどうかは誰にもわかりません...

1)数年前にgitを使い始めたとき、顧客は非常に遅く、信頼性の低い別のSCMを好みました(結局、これはSCMのNOGOの一種です(o;)。gitを使用しました)。他のSCMの上にある「プライベート」で、ネットワーク共有上の「ファイルベースの」リモートを使用し、製品の新しいバージョンがリリースされた後でのみSCMにチェックインします。

8
Timothy Truckle

あなたの環境

まず第一に、私は多くのコメントと回答で示されるほど悲観的ではありません。はい、これは「石器時代」ですが、かなり悪い状況があります。全体的な作業環境(同僚、場所、給与、興味深いプログラミング作業など)が問題なく、好みに合っている場合は、必ずそれに従ってください。 ITに関しては、それがそうです。これは政府機関だけでなく、銀行、保険、またはセキュリティや非常に古い構造に非常に重点が置かれている場所でも発生します。

USBスティックを挿入してそこから.exeを実行すると、すぐに他の場所で終了するので、何かを回避することはお勧めしません。

もう一度gitを試してください

今あなたの選択に。 svnではなくgitを強くお勧めします。とにかく1人でプロジェクトを行っている場合、gitは単なるローカルディレクトリです.gitアプリケーションルート内で、他には何もありません。

上司/ ITに「SCM」を要求するのではなく、gitをマシンにインストールして、開発をより速く、より高品質で行えるように依頼してください。 notコードを別の場所にプッシュしたい、notどこかで実行されているサーバーが必要、そしてnotかなりのスペースまたはメンテナンス時間を使い果たします。

Gitを使用すると、自信を持って作業でき(行った変更を元に戻すことができるため)、速度と品質が向上し、同時に複数のブランチで作業できるようになります。つまり、大規模なタスクで作業していて、すぐに注意が必要な何かが発生した場合は、新しいブランチに切り替えてすぐに修正し、実行時間の長いタスクに戻ることができます。

手動で行う

それがまったく不可能である場合は、もちろん手動のソース管理を行うことができます。コードを自分でコピーして、手動の「タグ」を作成します(おそらく、日付/時刻と変更点の簡単な説明を含む新しいディレクトリを作成します)。変更ログは、変更だけでなく変更したファイルの詳細なリストと、場合によってはさらに詳細にしてください。

もう一度、作業をコピーして「ブランチ」を作成し、マージするときは、任意の「diff」または「diff3」ツールを使用してクリエイティブを取得します-使用できるかどうかはわかりませんが、探し出す。

これらすべてに時間がかかる場合は、SCMをエミュレートすることが本当に価値があるかどうかをよく検討してください。 is価値があるとわかった場合は、上司と再度話します。手動SCMの利点を見せてください(「私はすべての古い作品のコピーを持っている」だけでなく、「バグXYZが発生したとき、5リリース前に理由をすぐに見つけることができました」)。次に、これがgitでどれだけ速くなるかを伝えます。

明らかに、これがあなたを夢中にさせるなら、仕事を探すことは常にオプションです。

7
AnoE

ここの多くの人々がこの質問の「政府機関」を見逃していると思います。一部の政府ネットワークは、許可されたソフトウェアに対して非常に厳しい規制を設けており、それらのルールを破ることは、おそらく犯罪者でさえ、発砲可能な犯罪です。ソフトウェアをインストールする際に、承認された動きが得られるかどうかを確認するために、管理を通じてプッシュします。私はカウボーイに行ったり、自分でインストールしたりはしません。 Linux/UNIXを実行している場合は、RCS(ci/coコマンド)またはSCCS(sccsコマンド)がインストールされているかどうかを確認してください。これらは、かなり標準的であった古いSCMツールです。それはきれいではありませんが、私が以下に書こうとしているものより優れています。 :)

「たくさんの」ディスク容量があるので、ソースツリーを作成します。小規模のSCMの基本は何ですか?変更をチェックインし、変更内容を確認したり、タグ付けしたり、必要に応じて古いバージョンに戻したりできる。ソースツリーの1つ上のレベルで、使用可能なものに応じて、次の処理を行うMakefileまたはスクリプトを作成します(これらはLinux/UNIXフレーバーであり、Windowsコマンドは異なる場合があります)。

チェックインを作成-cp -a source-tree source-tree-date(少なくとも分まで、秒でない場合は、source-tree-20171205115433など)

make status-diff -R source-tree source-tree-date |少ない(ここには小さなロジックがあり、デフォルトでは最新のバックアップが使用されるか、バージョンと比較するための引数が与えられます)

make tag-ln -s source-tree-date release1.0(特定のバージョンへのリンクを作成)

make revert-rm -r source-tree && cp -a source-tree-date source-tree

5
Matt Piechota

彼らに売る

あなたは残しました このコメント

彼らはネットワークドライブを持っていますが、それは私にはわかりませんが、定期的にバックアップを作成します。はい。私はそれを使用し、自分のアプリをそこに保存しています。

上司に行き、次のように言います。

ボス、私は私たちがネットワークドライブにアプリを配置し、ある種のサービスがバックアップを作成し、履歴を追跡するシステムがあることに気づきました。これを行うことで、独自のソース管理システムを実装しているように見えます。おそらく、SVNやgitのような専用のソース管理システムに切り替えることで、多くのスペースを解放し、システム全体を大幅にシンプルにすることができます。多くの利点があります。履歴バージョンのより簡単なバックアップ、時間の経過とともにファイルに加えられた変更を理解するためのツール(デバッグに非常に役立つ情報)、間違いを元に戻す簡単な方法、およびさまざまな人の変更を組み合わせる簡単な方法。

私は以前にこの種のシステムを使用したことがあり、カスタムセットアップが実行するタスクには非常に優れています。彼らと間違えることは、現在のシステムよりもはるかに困難です。それらはまた、非常に成熟し、広く使用されているテクノロジーです。これらのツールは20年以上にわたって広く使用されています。さらに、ライセンスに費用をかけることなく、最も人気のあるソフトウェアを使用できます。

クライアントとサーバーの選択と設定をお手伝いさせていただきます。それは[insert estimate here]マシンを入手できれば、インストールに数時間かかります。ネットワークを介してアクセスできる限り、どのマシンでも使用でき、古いデスクトップも廃止されます。

ここでの高レベルの要約は、彼らが理解できる、そして価値があると考える可能性が高い言葉でそれを置く必要があるということです:

  • 他の目的のためにリソース(ハードウェアと人)を解放する
  • リスクの低減(人為的ミス、安定したテクノロジー)
  • 生産性の向上
  • 実装コストが少ない

上司は技術者ではなく、技術的な問題を気にしません。しかし、moneyとお金のかかるもので問題を組み立てることができれば、彼らの耳は少し元気になるかもしれません。

4
jpmc26

技術的なソリューションが不足しています。政治的解決策だけが残っています。

1)開発者を統一します。すでに労働組合が存在する場合は、開発者である従業員の階級を公平に代表していないという立場に異議を唱えます。開発者の組合を結成しても開発者の半分の支持を得られない場合は、GO。あなたは体調不良です。

2)新聞広告。もしあなたの政府が自由な言論を認められた法律問題として保証しないならば、これはあなたを解雇させます。

1
Joshua

さて、あなたの質問とたくさんのコメントを読んだ後、私はあなたが次の制約/シナリオを持っていることを理解しました:

  • プロジェクトごとに1人。
  • プロジェクトにVisual Studio 2005以外の外部ツールを使用することはできません。 GITやその他のSCMは使用できません。
  • ローカルで作業している間は、プロジェクトを壊れた状態にすることはできません。時々自動バックアップがあり、常に機能させる必要があるためです。
  • 変更を追跡するには、履歴が必要です。

Visual Source Safe(VS 2005で動作するプラグインがある)を使用できない場合は、別のアプローチを使用できます。

上記の項目に基づいて、以下のようなプロジェクトフォルダーを整理することをお勧めします:

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

ここに従うべき基本ルール:

  • コードコントロールはプロジェクトのフォルダー内で実行されます。
  • 「トランク」で作業することはありません;
  • 「temp」で作業します、実装単体テスト、呼び出しbuild.bat、次にsave_on_trunk.bat;
  • 重要:完全に分離して実行される単体テストを実装します。新しいコードがトランクを壊さないことを保証するためにこれが必要です。
  • 自動バックアップがあるので、コードを失う可能性は少なくなります。したがって、「トランク」コードを常に動作状態にするだけで済みます。
1
Emerson Cardoso

サーバーをまったく使用せずに、裸のディレクトリでgitを実行するだけです。ディレクトリをバージョン管理できるので、他の誰もバージョン管理を使用しなくてもかまいません。 Gitはまさにこの不正なSCM導入シナリオ用に設計されており、うまく機能します。

恐竜がバケツを蹴って拡散するのを待つ必要がある場合でも、2人目が使用を開始するとヒーローになります。現在、SCMなしで大規模なコードベースを管理することはできません。実際には、何も監査せずにビジネスを運営するようなものです。

0
Rob

Git for Windowsには "ポータブル"バージョン があります。これをPCにコピーするか、メモリスティックに保存しておけば、実際に何かをインストールする必要はありません。問題が単にインストールである場合、これは回避策になります。

SCMに全面的に反対する場合は、ISO-9001、DO-178B、またはその他の関連するソフトウェア開発標準について、先のとがった質問をすることをお勧めします。

0
Graham