独自のデータベース移行/バージョン管理ソフトウェアを書くのは正しいですか？
私は、職場で使用するデータベーススキーマをバージョン管理し、バージョン管理下で移行を可能にするツールの作成に取り組み始めました。既存のツールについての私の最初の調査は、間違ったキーワードを検索したために大雑把であることが判明し、現在 Flyway および Liquibase を認識しています。さて、このペットプロジェクトをスクラップして、これらのツールの1つを使用する方が良いのではないかと思っています。
背景：私たちは小さなチーム、つまり1人の開発者と複数のシステム管理者およびドメインの専門家で働いています。彼らはソフトウェアを使用しますが、何も書くことは期待できません。私たちが内部で使用するさまざまなソフトウェアプロジェクト（ここではWebプラットフォーム、そこにいくつかのETLプロセス）とは別に、内部ソフトウェアプロジェクトをさまざまなキャパシティで使用するクライアントごとのプロジェクトもあります。あいまいに聞こえますが申し訳ありませんが、詳しくはお話しできません。
これはすでに、独自のツールを作成する必要があるかもしれない1つのことです。私が知る限り、上記の両方のツールはスキーマとプロジェクトを区別しません。任意の数のプロジェクトで同じスキーマを使用する必要があります。それでも、これらのツールをこのタスク用にカスタマイズする簡単な方法があるかもしれません。
私たち自身のツールを書くことには明らかに多くの不利な点があり、私が見ることができる他の唯一の取り込みは、100万行のコードを理解する必要があることに比べて、ツールに精通している場合、ツール自体の開発ははるかに簡単です。
また、ツールはチーム全体で使用できるようにできるだけ単純である必要があると主張することもできますが、「商用」ツールの1つのラッパーは、カスタムツールを完全に機能する状態にするよりも、おそらくあまり機能しません。
ここで私が求めているのは、ここで「構築と購入」の他の側面を考慮に入れなければならないことです。すべては、ソリューションを実行可能にするために注がれた予想作業時間に帰着しますか？独自のソリューションを作成する価値はありますかever？
独自のソリューションを作成する価値はありますか？
理論的には違います。それがあなたの会社の製品であるか、まったく利用できない場合を除き、既成のコンポーネントを使用する必要があります。そして、そこには多くのDBバージョン管理ソフトウェアがあります。
あなたの時間はあなたの製品に機能を追加するのに費やされます
The Registerの記事を読んだときのことを覚えています。数年前、彼らはさまざまなTech CEOを集めて、それぞれの会社のTechプロジェクトについて話していました。彼らは、標準ソフトウェアにカスタマイズを組み込むために何百万ドルも費やしており、後から考えると、代わりに内部プロセスを変更してソフトウェアと一致させる必要があることに気付きました。
これは、レガシーツールが現在のベストプラクティスと互換性がなく、数年前に内部で構築され、開発者が去った、または請負業者によってカスタマイズが追加されたために移行パスがないという多くの人々の経験に一致すると確信しています。インストールされたとき。
実際には、要件が限られていて予算がない中小企業にとって、自分で何かを書くことは、何もないよりはましだろう。ただし、できるだけ早くカスタムメソッドから移行する必要があります。
独自のソリューションを作成する価値はありますか？
絶対に-しかし、限られた状況でのみ：
独自のテクノロジーを強化するため
お使いのソフトウェアには特定の機能があり、開発を大幅に行わないと、他のサードパーティ製ソフトウェアと簡単にやり取りすることが難しい場合があります。
ソフトウェアは存在しません
単に存在せず、おそらく存在しないソフトウェアが必要になる場合があります。ヒント：製品[〜＃〜] x [〜＃〜]に機能[〜 ＃〜] y [〜＃〜]「もうすぐ」。
専門の機能が必要です
ソフトウェアは利用できますが、既存のシステムとのインターフェースが簡単ではないか、十分に機能しない可能性があります。非常に大きなデータファイルを分類するソフトウェアを調達する以前の役割のダースベンダーを見ていたのを覚えています。それらはすべて、一般的な並べ替えテストで見事に機能しましたが、データに苦労していました。最後に、独自の並べ替えソフトウェアを作成したところ、快適にすべてを上回っていました。私たちのテクノロジーをベンダーに売り戻すことについての問い合わせもいくつかありました。
それはあなたが先に進んでそれをやるべきだと言っているのではありません-それが完全に正しい決定であることを確実にするためにデューデリジェンスが行われるべきです。
標準の製造/購入の決定は別として、それをアウトソーシングすることを検討したい場合があります。これにより、リスクを（エスクローの形で）共有しながら、日々の作業に集中できます。単独のトレーダーを危険にさらしたくない場合、人材紹介会社は多くの場合、開発者が一定の手数料で作業を完了できるようにしてくれます。
自分で書くことには利点があると思う場合に、少しニュアンスを持たせたいと思います。
- 既製のソリューションのほんの一部しか必要としないことが定期的に起こります。既成のソリューションではすべてのケースとすべての状況を考慮する必要があるため、特定のケースではかなり肥大化する可能性があります。
- さまざまな既成のコンポーネントを一緒に動作させるためのすべての配管は、プロジェクトに悪影響を与える可能性があり、自分で何かを記述します（JavaScriptコミュニティでは個人的にこれがうまくいかないと思います）
- 複雑なプロジェクトが既製のソリューションを完全に統合する場合、それを独自の製品/パイプラインに完全に統合するためだけに多くの醜い回避策を構築する必要があることを意味します。私は、ある時点で親会社によってプッシュされていた"tool/editor framework"を廃止した大規模なゲーム会社で働いていました。大変な努力だったと思いますが、多くの回避策のコードを捨てて、実際に美しく統合され、ハッキング/プラグイン/その他の配管が少ないものを作ることができました。もちろん、ゲーム会社にとって、編集ツールはコアビジネスに非常に近いものです。
しかし、他の両方の答えは素晴らしく、この特定のケースでの私の直感は、あなたもあなた自身のものを書くべきではないということです。
これは興味深いケースです。
通常、そしておそらくこのケースでも、あなたはすぐにあなたの最愛の人を殺し、既製のソリューションを実装するべきです。
ただし、ベア移行パッケージは非常に単純なソフトウェアです。ほとんどの既製のパッケージは、データベース抽象化レイヤーを含み、アプリですでに使用しているパッケージを使用するだけなので、肥大化しすぎています。ニーズにぴったり合うように独自のソリューションを調整できます。
あなたの例で述べたように、マルチテナンシーで。私たちが使用しなければならないソリューションは、プロジェクト/顧客ごとに個別の移行テーブルがあり、それぞれに独自の構成ファイルがあります。これは、必要のない多くの複製です。
したがって、本当にシンプルに保つ限り、独自のソフトウェアを使用する方が良いでしょう。ただし、追加の機能が必要な場合は、それを削除して、既製の製品を入手してください。