私は政府機関で働いています。ここで使用されているテクノロジーとソフトウェアを開発する方法はかなり古いものです。
大量のストレージスペースがありますが、ここでのほとんどの作業を自動化するために使用されるアプリケーションを維持および維持するための適切なスペースがありません。
この機関では、GITやSVNなどのSCMソフトウェアを使用できません。
コードの品質を維持し、後でアプリに新しい機能を追加できるようにするための最良のアプローチは何でしょうか?
コードを壊すことなく、コードに加えた変更をどのようにして記憶できますか?
編集:私は言及するのを忘れていました、彼らは各コンピュータ用のネットワークドライブを持っています、そしてどういうわけかこれらのネットワークドライブは定期的にバックアップを作成または保存します。ただし、自分の作業を保存し、既存のコードを壊すことなく新しい機能を追加できるようにする独自の計画を作成しない場合、SCMソリューションに勝る大きな利点はありません。
編集:多くの人々がポータブルGitを提案したので、もっと情報を追加する必要があります。 Visual SVNサーバーをインストールしようとしましたが、インストールする管理者権限がないため失敗しました。通常のGit Shellもダウンロードしてみましたが、ファイアウォールまたはネットワーク設定でGitダウンロードページにアクセスできませんでした。私も、Gmailである私のメールにポータブルGitを送信してみました。 Googleはパッケージ内のexeファイルを検出しましたが、それでも、仕事用のコンピューターにポータブルGitバージョンをダウンロードできませんでした。私が言及しなければならないもう1つのことは、教育機関を通じてコンピューターに適用されるネットワークポリシーは、USBストレージデバイスの使用を許可していません。 USBポートを使用して、スマートフォンを充電したり、小型スピーカーなどのガジェットに電力を供給したりできます。また、一部の人々が述べたように、インターネットでさえも許可されていないコンピュータがあります。
3つのシンプルなツールを使用して、ソース管理が果たす役割を大まかに複製できます。
基本的に、ワークフローは次のようになります。
SVNやTFSのような、よりモノリシックなソース管理システムは、基本的に、舞台裏でこれを行います。
現実は、これはバス会社がドライバーにバッテリーのあるバスを運転できないと伝え、ドライバーにバスを坂を押し下げ、クラッチをポップしてバスを始動させるようなものです...これはひどい現在の経営陣はバスガレージの運営について何も知らないことを示しています。お悔やみ申し上げます。
しかし、少なくともあなたはバスを始めることができます。
コンセンサスは確かにこの会社では機能しないとは思いますが、それが本当にあなたの質問に答えるとは思いません。
SCMを実際に置き換えることはできません。
あなたは本格的なシステムの通常のベルとホイッスルを必要としないかもしれません。たとえば、会社はサーバーの要求を拒否しても、ローカルSCMの使用を許可する場合があります。彼らはgitが嫌いかもしれませんが、Subversion(または他のバージョン管理システム)を許可しています。
もちろん問題があります。あなたの同僚は何を使っていますか、または以前の労働者は何ですか?あなたが彼らが持っている最初のソフトウェア開発者であるなら、それはあなたが必要とするリソースのために非常に強く押すあなたの時間です。
結局、会社が自分の役割と経験を尊重せず、必要なツールを許可しない場合、ソース管理の欠如よりもさらに深刻な(そしてストレスの多い)問題が発生することになります。
基本的に、管理上の問題(組織が ソフトウェア開発プロセスの基本を理解していない 、たとえば Vモデル )が、現在の最小限のワークフロー、方法論、とツール。これは一般的です( ピーターの原理 について読んでください)。
ところで、2017年末のパリでの最近の SNCF鉄道インシデント にも同様の原因があると思います(高度な管理レベルでのソフトウェア文化の完全な欠如、したがって、パリの主要な鉄道駅の1日以上の閉塞;もちろんSNCFには非常に有能なITチームがいますが、彼らは主要な決定について相談を受けていません。ソフトウェア文化がまったくないヨーロッパのいくつかの産業を挙げれば、アメリカでも同様のことが見つかるはずです。
主な問題は次のとおりです:コードベースで一人で作業していますか、それとも同僚と作業していますか?
単独で作業している場合は、コンピューターのローカルで git を使用して、コード(およびおそらく.git
リポジトリ)定期的に(その外部ストレージスペースに)。半日以上の作業を決して失わないようにしてください(したがって、定期的かつ確実にデータをバックアップしてください)。
(私はあなたが少なくともgit
とsvn
の両方を知っていて、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
のソースコードをコンパイルする許可を(上司に)尋ねる必要があります。彼は、そのソースコードを外部から仕事用コンピューターに転送することに関する実際の詳細(彼がそのような解決策を受け入れる場合)についてあなたに説明するか、または彼と話し合います。
私が最初に行うことは、政府機関(おそらくIT部門)が反対していることを具体的に識別することです。ストレージスペースはあるがサーバー用のVMをホストする方法がない場合、問題はIT部門がSVNまたはGIT serverにノーと言っていることであり、それは大きな違いです。問題が発生国である場合、つまり私たちは外国のエンティティによって作成されたツールを信頼していません-それは別の問題です。
GITはファイルシステム内で完全に実行できます。これは、私が幼児プロジェクトで何かをする準備ができる前に行ったものです。 GITのインストールにも管理者権限は必要ありません。
何らかの理由でGitを絶対に使用できない場合は、いくつかのオプションを利用できます。
patch
とdiff
がずっと前(80年代)に作成されたのには理由があります。それらはバージョン管理を可能にした実現技術でした。70年代の発展はどのようなものですか?それはきれいではありませんが、それが私たちが始めた方法です。アプリケーションははるかに小さかった。基本的に、彼らにはいくつかの共通点がありました:
patch
およびdiff
が必要な場所です。基本的に、これはエラーが発生しやすいプロセスであり、問題が発生する可能性が高くなります。 「ブランチング」のアイデアは実装が簡単ですが、管理するのは悪夢です。主な問題は、ソースコードのコピーが多すぎる場合、本番環境の正しいベースラインが何であるかを理解することが難しいことです。実用性のために、あなたはシングルスレッドになる必要があります。
これは、代替案の分析に含める必要があるものです。
コメントで言及した制約を考えると(例:Gitダウンロードページ、Windowsプラットフォームにアクセスできず、Visual Studio 2005を使用して)、2つのオプションが表示されます。どちらも以前に同じような状況で使用したものです。
たくさんの収納スペースがあります
決定時にそれを使用することは許可されていますか?
もしそうなら、あなたはfile systemリモートリポジトリを作成することができます。欠点は、git
がリポジトリ全体をダウンロードして変更を探す必要があるため、プロジェクトの成長中にプッシュが遅くなることです...
これまでのところ、コンピュータは通常のユーザーのように動作しており、サードパーティのソフトウェアをインストールすることはできません。
git
はportable appとしても提供されるため、$ HOMEまたは%USERPROFILE%パスにインストールできます。
結論として:SCMの使用を禁止しないでください。1。 「プライベート」で使用します。結局のところ、どこかでチェックインされているかどうかにかかわらず、コードが開発されたかどうかは誰にもわかりません...
1)数年前にgit
を使い始めたとき、顧客は非常に遅く、信頼性の低い別のSCMを好みました(結局、これはSCMのNOGOの一種です(o;)。git
を使用しました)。他のSCMの上にある「プライベート」で、ネットワーク共有上の「ファイルベースの」リモートを使用し、製品の新しいバージョンがリリースされた後でのみSCMにチェックインします。
まず第一に、私は多くのコメントと回答で示されるほど悲観的ではありません。はい、これは「石器時代」ですが、かなり悪い状況があります。全体的な作業環境(同僚、場所、給与、興味深いプログラミング作業など)が問題なく、好みに合っている場合は、必ずそれに従ってください。 ITに関しては、それがそうです。これは政府機関だけでなく、銀行、保険、またはセキュリティや非常に古い構造に非常に重点が置かれている場所でも発生します。
USBスティックを挿入してそこから.exeを実行すると、すぐに他の場所で終了するので、何かを回避することはお勧めしません。
今あなたの選択に。 svnではなくgitを強くお勧めします。とにかく1人でプロジェクトを行っている場合、gitは単なるローカルディレクトリです.git
アプリケーションルート内で、他には何もありません。
上司/ ITに「SCM」を要求するのではなく、git
をマシンにインストールして、開発をより速く、より高品質で行えるように依頼してください。 notコードを別の場所にプッシュしたい、notどこかで実行されているサーバーが必要、そしてnotかなりのスペースまたはメンテナンス時間を使い果たします。
Gitを使用すると、自信を持って作業でき(行った変更を元に戻すことができるため)、速度と品質が向上し、同時に複数のブランチで作業できるようになります。つまり、大規模なタスクで作業していて、すぐに注意が必要な何かが発生した場合は、新しいブランチに切り替えてすぐに修正し、実行時間の長いタスクに戻ることができます。
それがまったく不可能である場合は、もちろん手動のソース管理を行うことができます。コードを自分でコピーして、手動の「タグ」を作成します(おそらく、日付/時刻と変更点の簡単な説明を含む新しいディレクトリを作成します)。変更ログは、変更だけでなく変更したファイルの詳細なリストと、場合によってはさらに詳細にしてください。
もう一度、作業をコピーして「ブランチ」を作成し、マージするときは、任意の「diff」または「diff3」ツールを使用してクリエイティブを取得します-使用できるかどうかはわかりませんが、探し出す。
これらすべてに時間がかかる場合は、SCMをエミュレートすることが本当に価値があるかどうかをよく検討してください。 is価値があるとわかった場合は、上司と再度話します。手動SCMの利点を見せてください(「私はすべての古い作品のコピーを持っている」だけでなく、「バグXYZが発生したとき、5リリース前に理由をすぐに見つけることができました」)。次に、これがgit
でどれだけ速くなるかを伝えます。
明らかに、これがあなたを夢中にさせるなら、仕事を探すことは常にオプションです。
ここの多くの人々がこの質問の「政府機関」を見逃していると思います。一部の政府ネットワークは、許可されたソフトウェアに対して非常に厳しい規制を設けており、それらのルールを破ることは、おそらく犯罪者でさえ、発砲可能な犯罪です。ソフトウェアをインストールする際に、承認された動きが得られるかどうかを確認するために、管理を通じてプッシュします。私はカウボーイに行ったり、自分でインストールしたりはしません。 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
あなたは残しました このコメント :
彼らはネットワークドライブを持っていますが、それは私にはわかりませんが、定期的にバックアップを作成します。はい。私はそれを使用し、自分のアプリをそこに保存しています。
上司に行き、次のように言います。
ボス、私は私たちがネットワークドライブにアプリを配置し、ある種のサービスがバックアップを作成し、履歴を追跡するシステムがあることに気づきました。これを行うことで、独自のソース管理システムを実装しているように見えます。おそらく、SVNやgitのような専用のソース管理システムに切り替えることで、多くのスペースを解放し、システム全体を大幅にシンプルにすることができます。多くの利点があります。履歴バージョンのより簡単なバックアップ、時間の経過とともにファイルに加えられた変更を理解するためのツール(デバッグに非常に役立つ情報)、間違いを元に戻す簡単な方法、およびさまざまな人の変更を組み合わせる簡単な方法。
私は以前にこの種のシステムを使用したことがあり、カスタムセットアップが実行するタスクには非常に優れています。彼らと間違えることは、現在のシステムよりもはるかに困難です。それらはまた、非常に成熟し、広く使用されているテクノロジーです。これらのツールは20年以上にわたって広く使用されています。さらに、ライセンスに費用をかけることなく、最も人気のあるソフトウェアを使用できます。
クライアントとサーバーの選択と設定をお手伝いさせていただきます。それは
[insert estimate here]
マシンを入手できれば、インストールに数時間かかります。ネットワークを介してアクセスできる限り、どのマシンでも使用でき、古いデスクトップも廃止されます。
ここでの高レベルの要約は、彼らが理解できる、そして価値があると考える可能性が高い言葉でそれを置く必要があるということです:
上司は技術者ではなく、技術的な問題を気にしません。しかし、moneyとお金のかかるもので問題を組み立てることができれば、彼らの耳は少し元気になるかもしれません。
技術的なソリューションが不足しています。政治的解決策だけが残っています。
1)開発者を統一します。すでに労働組合が存在する場合は、開発者である従業員の階級を公平に代表していないという立場に異議を唱えます。開発者の組合を結成しても開発者の半分の支持を得られない場合は、GO。あなたは体調不良です。
2)新聞広告。もしあなたの政府が自由な言論を認められた法律問題として保証しないならば、これはあなたを解雇させます。
さて、あなたの質問とたくさんのコメントを読んだ後、私はあなたが次の制約/シナリオを持っていることを理解しました:
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)
ここに従うべき基本ルール:
サーバーをまったく使用せずに、裸のディレクトリでgitを実行するだけです。ディレクトリをバージョン管理できるので、他の誰もバージョン管理を使用しなくてもかまいません。 Gitはまさにこの不正なSCM導入シナリオ用に設計されており、うまく機能します。
恐竜がバケツを蹴って拡散するのを待つ必要がある場合でも、2人目が使用を開始するとヒーローになります。現在、SCMなしで大規模なコードベースを管理することはできません。実際には、何も監査せずにビジネスを運営するようなものです。
Git for Windowsには "ポータブル"バージョン があります。これをPCにコピーするか、メモリスティックに保存しておけば、実際に何かをインストールする必要はありません。問題が単にインストールである場合、これは回避策になります。
SCMに全面的に反対する場合は、ISO-9001、DO-178B、またはその他の関連するソフトウェア開発標準について、先のとがった質問をすることをお勧めします。