バージョン管理と継続的インテグレーションを使用しない深刻な企業はありますか？どうして？
私の同僚は、継続的インテグレーションを備えたビルドサーバーとバージョン管理ソフトウェアの両方を使用していたため、ソフトウェア部門が非常に高度であるという印象を受けました。これは私の考えとは一致しませんでした。私が真面目なソフトウェアを作り、どちらも持っていない会社を1つだけ知っていたからです。しかし、私の経験はほんの一握りの会社に限られています。
誰か本当の会社を知っていますか（3人以上のプログラマー）、これはソフトウェアビジネスでこれらのツールを使用していませんか？そのような会社が存在する場合、彼らがそうしない理由はありますか？
あなたが彼らを深刻な行為と呼ぶかどうかはわかりませんが、MySpaceはこの面ではかなり貧弱です。参照 http://highscalability.com/blog/2011/3/25/did-the-Microsoft- stack-kill-myspace.html 。
現実が常識に対して何ができるかを見ると、あなたは驚くでしょう;-)
バージョン管理システムを使用していない企業はまだまだたくさんあると思います。興味深いことに、これまでに見たすべてのケースで、そのようなシステムの使用に積極的に反対しているのではなく、SVNのようなものが存在することを彼らが知らないためです。私に関しては、私はあなたに完全に同意し、いかなるバージョン管理も使いたくない状況を想像することはできません。地獄、私は自宅のPCにある自分の個人ファイル（Word文書など）をGITリポジトリにプッシュしています。
継続的インテグレーションシステムの場合、日常の運用ではそれらを使用しない方が少し一般的です。時々また、人々がそのようなシステムが存在することを知らないので、私はそれらを使用しないことの非常に疑わしい言い訳が「十分に複雑ではない」または「継続的な統合なしで非常にうまく機能している」というケースを見たこともあります。では、なぜ別のテクノロジーを追加する必要があるのでしょうか？」もちろん、これは現実的な評価にはなりませんが、元の質問に答えるには、すべてではありませんそれ珍しいことです。
私の業界（銀行）のほぼすべての会社が現在バージョン管理を使用しています。しかし、バージョン管理なしでソフトウェアを開発することは確かに可能です。 20〜30年前。私たちはまさにそれをしました。
私は、多くの銀行、おそらく大多数の銀行でさえしないでください継続的インテグレーションのビルドサーバーを使用すると言います。継続的な統合をせずにすでにソフトウェアを正常に配信している場合は、その道を進むのは完全に合理的です。
ちょうど@RoadWarriorの答えに反対の点を指摘するために：
私は銀行で働いています。私は過去3年間、バージョン管理の実装に費やしてきましたが、今ではコードベースの約20％でそれを実現することができました（これは非常に大きく、約20人の開発者がいて、16年以上システムを開発しています）
業界（銀行）での連絡を通じて、私はtonを知っています。他の金融機関では、正気な人がバージョン管理と呼ぶものを持っていません。
はい、私たちの業界（ソフトウェア開発）は、ほとんどの人が認めたいよりもずっと悲しいです。
バージョン管理：25年前の最初の仕事では、そのようなバージョン管理システムはありませんでしたが、これはPDP-11上のRSX11でした。しかし、設計とコードの正式なレビューを伴うvery高レベルの品質管理がありました（これは原子力業界にありました）。
それ以降のすべてのジョブでは、SCCS、PVCS、クリアケース、CVS、PERFORCEなどのバージョン管理システムを使用しています。
したがって、私の経験では、バージョン管理の使用は、深刻なソフトウェア開発ではかなり普遍的です。
継続的インテグレーション：これは、特に、自動テストの方法があまりないレガシーコードがたくさんある場所では特に問題になります。既存のコードをCI環境に移行するには非常に大きな投資が必要です。おそらく最終的には成果を上げますが、短期的な利益なしに経営陣にそのような投資をコミットさせることは困難です。
私は1つの場所（大規模な銀行）で働いていて、いくつかのプロジェクトにCIが配置されていました。私たちはプロジェクトに一種のCIシステムを実装しました。
ほとんどの企業はこれらのことを使用していないと思います。彼らは利点を理解しておらず、開発者は学びたくないか、以前とは異なることをすることで「かき混ぜる」ことを恐れているからです。前に行われました。
私は今は従業員ですが、以前はデータベースコンサルタントとして自営業をしてきました。その長い年月の間に、私はママとポップのレベルからフォーチュン100まで、800から1000の会社のどこかにいました。
継続的インテグレーションを行う場所は比較的少数でしたが、バージョン管理を使用していない会社を見たことはありません。バージョン管理されたコード用の集中化されたリポジトリがない場所をいくつか見ました。個々のプログラマーは、自分のコンピューターでバージョン管理を使用するか、サーバーのホームディレクトリの下のどこかにバージョン管理されたコードを保持していました。
私はこれらのどれもcompaniesがソフトウェアビジネスにいたとは思わないが、彼らのプログラマーは確かにそうであった。
複雑なアプリケーションとタスクのリストで作業するときに2人のプログラマーがいても、お互いの変更を妨害しないことは難しい場合があります。
私たちの古いリリース管理ソフトウェアでさえ、変更を並べて表示し、どちらの方向にも適用できるようにしました。変更がなければ、変更が複数回失われることになります。
CIには多くのメリットがありますが、どの会社がバージョン管理ソフトウェアを利用しないのか、想像できません。
私がバージョン管理なしで作業した最後の仕事は2006年でした（私はFWIWのWeb開発者です）。この会社には、私を雇う前に約2〜3人の開発者しかいませんでしたが、私はたった数か月で10人ほどの開発者を雇いました。採用時に最初にしたことの1つはバージョン管理の導入（CVS、当時はどれほどひどいかわからなかったためです！）環境なので、使用しませんでした。ああ、私は彼らが実行しているアプリケーションのローカルインスタンスさえ持っていなかったと言ったか？彼らはサーバー上のコードをハッキングした。もちろん、自動テストはありません。振り返るとうんざりします。
その前に、バージョン管理なしでAS/400プログラミング作業を行いました。まともなVCSがその環境で利用できるかどうかさえわかりません。
現在、私はすべての1人のプロジェクトにGitを使用しており、最近のいくつかの仕事でもGitを使用しています。
CIは別の問題です。それは素晴らしいことであり、私はそれを奨励しますが、少なくともインタープリター言語の小規模なプロジェクトでは、バージョン管理ほど重要ではありません。しかし、最近の仕事のほとんどにCIサーバーがありました。とりわけ、それはデプロイする前に完全なテストスイートを実行することを誰も忘れることができないことを意味します。
私の同僚は、継続的インテグレーションを備えたビルドサーバーとバージョン管理ソフトウェアの両方を使用していたため、ソフトウェア部門が非常に高度であるという印象を受けました。
いいえ、私はそれを言うのが嫌いですが、これは本当です。私が働いていた最後の2か所（銀行の部門と金融会社）で、バージョン管理システムを実装したのは私でした。多くの場所（特にソフトウェア以外のショップ）は、長期的な開発に本当に必要な理由を理解していません。チームは通常、1人か2人で始まり、そこから苦痛を伴いながら成長します。 1人または2人の場合、お互いにほぼ常にコミュニケーションを取ることができるため、それなしで（うまくいかない）うまくいくことができます。
継続的ビルドは完全に異なるケースです。推測する必要があるとしたら、開発が行われている場所のほぼ90％にCIソリューションがないことでしょう。私は会議に行きますが、ほとんどの人はMSまたはGoogle以外の組織が持っていることに驚いています。私が発見したのは、多くの時間を節約できるとしても、経営陣はそれを稼働させるために少額のお金を費やしたくないということです。
これについて私が見つけた最大の理由は次のとおりです。
管理職の人々は、同じ組織の階級を通じて昇進しました。彼らは一度も使用したことがなく、それを必要としなかったのに、なぜ今変更する必要があるのでしょうか？私が見つけたいくつかはただ変化を恐れています。新しいものは恐ろしいです、そしてそれは彼らが彼らの古いコンパイラをこすり落とすのを防ぎ、必要な時に私たちのより若いものを助けるでしょう。他の場合（そしてより頻繁に）、彼らは常にタイトな予算を持ち、どこにお金を使うかについて決定をしなければなりません。これらを実装することは明らかなニーズですが、それは以前に使用したことがあるからです。メリットはわかっていますが、わかりません。
マネージャーはIT以外の人々であり、ここでのすべては、以前には必要でなかった何かにお金を使いたいということだけです。
私が人々から聞いたほとんどの議論はベストプラクティスなどに集中しており、それらは真実ですが、ほとんどの開発者が理解していないことは、このシナリオでは財務状況の観点からそれを組み立てる必要があるということです。この金額を使用すると、Xの時間を節約でき、それをバックアップするための数値が必要になります。これは常に正しいとは限りませんが、私の過去の経験です。
自分でコーディングしている可能性があり、コードベースを中央サーバーまたはUSBハードドライブに定期的にバックアップするために使用されているため、多くの人々はソース管理を使用しません。長い目で見れば有益だとわかっていたので、1年ほど前にSVNの使用を強制しました。慣れるまで少し時間がかかりましたが、今では常に参照できる大量のコード履歴があります。始めて4年前に実装したことを願っています。
継続的インテグレーション？必要な場合にのみ使用してください。私の場合、ソフトウェアエンジニアは2人しかいないので、自分でソフトウェアを開発しているので、継続的インテグレーションのメリットはありません。
ハ、あなたはSCMとCIシステムを持っているのであなたは進歩していると思いますか？それは、アマチュアアワーの話です。
多くの企業が最低限必要なことを行っていますが、それだけです必要。それが機能し、大きな努力なしに再現性のあるリリースが得られれば、修正する必要のあるものは何もありません。そのような状況で最後にしたいことは、特に新しいサーバーのセットアップと管理とシステムの構築のために管理リソースを仕事から遠ざけることに関して、「修正」を始めることです。
ただし、企業によっては、ビルドを実行するだけでなく、コードレビュー、ワークフロースタイルのチェックイン手順を取り入れて、テスト計画とテスト結果を介して展開に至るまで要件を制御する、もう少し厳しいシステムが必要です。チームリーダーが指定したワークパッケージ管理。これが本当の構成管理です。そのような環境で作業する必要がないことをうれしく思います。
私はいくつかの会社で働いていましたが、なんらかの形のSCMを持っていなかった会社は思いつきません。それらのいくつかは他より包括的でしたが、それらのすべては、VSSを使用したものでさえ、それらのためにうまく機能するシステムを持っていました。
私は間違いなくあちこちでいくつかに出くわしましたが、ほとんどは小さな会社です。私がより頻繁に見る問題は、実際にはSCMを持っている会社ですが、多くのプロジェクトは小さすぎるか重要でないため、それらを追跡することはできません。