|
[51CTO 選訳] Difio は、パッケージの状態を追跡し、変更があった際にユーザーに通知するために設計された Django ベースのアプリケーションです。様々な変更分析オプションが用意されており、ユーザーは最新の情報に基づいてパッケージのアップグレードをいつ、どのように実施するかを決定できます。Difio 自体は標準的なクローズドソースソフトウェアですが、自宅での開発を可能にし、技術コミュニティからの参加者を増やすため、オープンソースプロジェクトにすることにしました。 簡素化する 数年間稼働しているアプリケーションには、使われなくなったコードや機能が必然的に蓄積されます。こうした不要な部分を削除することで、共有すべきコードはより純粋で簡潔なものになります。これはDifioのオープンソース化への取り組みの第一歩であり、既存のコードベースのサイズを約20%削減します。 具体的な職務は次のとおりです。
例えば、追加の依存関係や単発のコードを扱う際は、テンプレートとプレーンHTMLでドキュメント化していました。また、一度か二度しか使用しないカスタムテンプレートタグも設定していました。これらはすべて削除され、残ったテンプレートは高い一貫性を維持できました。 パス、値、URLなどの要素をハードコーディングすることは、ラピッドプロトタイピングにおいて避けられない要素であることは間違いありません。クローズドソースアプリケーションは開発環境から特定の特性を引き継いでいる場合があり、それらも調整する必要があります。必要に応じて、カスタムテンプレートタグと設定をいくつか使用しました。 自己完結型モジュールを作成する つまり、ファイル構造の再構築により、アプリケーションは簡素化され、より自然な操作感が得られます。自己完結的で独立したモジュールを作成することで、将来的にモジュール同士を分離しやすくなります。 DifioのウェブバックエンドはOpenShift上にデプロイされており、テンプレートと状態ファイルには異なるディレクトリレイヤーが使用されています。これらのファイルを移動し、Djangoの設定を更新して、より適切に読み込めるようにする必要がありました。また、生の静的ファイルをCDNバックエンドに送信する方法も再考する必要がありました。 内部コードと外部コードを分離します。 アプリケーション内で内部コードを使用して、より多くの情報を提供することは、全く理にかなっています。例えば、使用状況やその他の指標の追跡、課金、その他の機能を実装する際には、内部コードが不可欠です。Webサービスでは、このコードはコア機能に統合されていることが多いため、オープンソース化の重要な部分として、これを分離する必要があります。 変換プロセスにより、分離が必要なコンテンツと、理想的には保持すべきコンテンツを特定することもできました。例えば、Difio ではテストインスタンスを分離しません。これは、テストインスタンスを CI 環境から明示的に分離し、完全に Web サービスまたはスタンドアロンアプリケーションとして実行することに伴う追加のワークロードを削減するためです。 Difio には 5 つの独立したモジュールが含まれています。 1. difio（コアユーザーエクスペリエンスがここにあります） 2. 構成ファイルサブシステム 3. 請求モジュール 4. 管理者インターフェースを展開する 5. 関連モジュールの展開（ほとんどの設定はここから派生します） 上記のモジュールは明確に分離・独立しており、すべての入力と内部依存関係は削除されています。現在、difio/ は正しいデフォルト値を提供するために複数の設定ファイル API に依存しています。 このステップは、実用的なコンポーネント (カスタマイズされた電子メール テンプレートなど) をコア ユーザー エクスペリエンスから分離するのにも役立ちます。 コードリファクタリング 言うまでもなく、コードのリファクタリングとテストも継続的に取り組む必要があります。しかし、おそらく今頃は既存のソースコード全体（あるいは大部分）の簡単なレビューを実施し、改善が必要な部分を大まかに把握しているはずです。オープンソースへの移行はソフトウェアの品質向上の絶好の機会であり、これを逃さず活用すべきです。 さらに、この機会を利用して、修正が必要な脆弱性など、これまでに収集された公開された問題に関する情報を含む短期ロードマップを作成することができます。このロードマップは、新しいプロジェクトが開始当初からより大きなダイナミズムと改善への強い意欲を示すのに役立ちます。これらは、より多くの貢献者を引き付けるための鍵となる要素です。 Difioでは、新しいアプリケーション構造に適合させるために、いくつかのメソッドと内部コードの大部分をリファクタリングしました。この改善は必須というよりはむしろおまけのようなものなので、外部メソッドは今のところそのまま残し、後で修正する予定です。 法律業務 ソフトウェアの規模と複雑さに応じて、オープンソースへの移行に必要な時間は大きく異なります。適切なオープンソースライセンスの選択、ブランドの構築、製品における作者のクレジット表記、法務レビューの実施、特許侵害の可能性のあるコードの特定など、これらすべてを事前に検討しておく必要があります。 しかし、Difio のおかげでこの作業ははるかに簡単になりました。Apache 2.0 ライセンスを選択し、すべてのソースファイルにライセンスタイトルを追加し、インターネットで見つかった外部コードに関連する著作権および知的財産権の問題をすべて適切に解決しました（ほとんどの場合、アプリケーション自体にはこの点に関する具体的な条件は設定されていません）。 外部依存関係を更新して一覧表示する ソフトウェア開発者として、私たちは他のアプリケーションの最新バージョンへのアップグレードに対応するために、自社のソフトウェアが他のアプリケーションとスムーズに（あるいは少なくともある程度問題なく）動作することを保証しながら、特別な対策を講じる必要があります。自分のコードを実行するためだけにレガシーな依存関係を使わなければならない状況は誰も望んでいませんし、ほとんどの場合、それは不可能です。 さらに、ソフトウェアを実行する前に他の必要なプログラムをインストールする方法をユーザーが理解できるように、依存関係リスト（例：requirements.txtファイル）が必要です。幸いなことに、DifioはDjangoベースのアプリケーションであるため、アップグレードの問題はほとんど発生せず、外部ソリューションへの依存度もそれほど高くありません。 ドキュメントと例を提供する 私たちのオープンソースプロジェクトに初めて参加する方にとって、ドキュメントは極めて重要です。私たちの目標は、非常に魅力的なコミュニティを構築することであり、その目標を達成するにはオープン性を維持することが不可欠です。そのため、ドキュメントとサンプルの作成は極めて重要です。 Difio側では、セットアップ関連のすべての側面を詳細に説明したREADMEファイルを作成しました。これは、アプリケーションが複数のサブシステム（メッセージング層やスケジュールタスク管理など）を備えており、それぞれを様々な方法で設定できるためです。2つ目のドキュメントは「コンテンツ管理ガイド」です。すべてのタスクを自動化できるわけではなく、場合によっては手動による介入が必要になることは明らかであるためです。これら2つのドキュメントは、Difioの最も重要な設計および展開機能をすべて網羅していますが、独自のプロジェクトではさらにドキュメントを用意する必要があるかもしれません。 公開コードベースを作成する 今こそ、パブリック コードベースを作成し、ソフトウェア配信を開始するときです。 Difioオープンソースプロジェクトでは、最初のコミットとして、元の場所から difio/ ディレクトリ全体をコピーすることにしました。この方法の欠点は、過去のコミット履歴がすべて利用できなくなることですが、コードスニペットにハードコードされたキーとパスワードの漏洩を防ぐため、このアプローチを選択しました。 本番環境では、 difio/ ディレクトリを git サブモジュールに置き換えました。これは、リリース/デプロイメント サイクルを高速化するためと、クラウド環境でデプロイメント メカニズムとして git を選択したためです。 今後、ソースコードに対するデバッグと変更はすべて公開で行われます。 完全に新しい環境での単一マシンの展開のテスト これまで、既存のローカル コピーのデバッグや、依存関係、環境構成など、アプリケーションの以前のバージョンからのレガシー コンテンツのトラバースに、全員の注意が集中していた可能性があります。ただし、考え方を変えて、外部ユーザーの観点から完全に新しい環境でテストを開始する必要があります。これにより、ドキュメントをさらに改良し、レガシーの問題をクリーンアップできるようになります。 Difio をテストしているときに、これまで見落とされていた、または新たに出現したランタイム要件、欠落している、または不適切に処理された設定、およびエラーが発生しやすい、または不完全なドキュメントがいくつか見つかりました。 この作業を完了したら、慌てて休む必要はありません。各ステップが正しく解釈され、新しいデバイスに適用されるまで、最初からやり直してください。これにより、少なくとも将来のプロジェクト貢献者やユーザーが自分のコンピューターにソフトウェアをスムーズにインストールできるようになります。 リリース ついに最後の課題が到来しました！独自のプロモーション資料を作成し、新しいソフトウェアを世界に紹介しましょう。おめでとうございます！この瞬間から、あなたは正式にオープンソースコミュニティに参加したことになります！ 元のリンク: http://opensource.com/business/14/5/10-steps-migrate-closed-to-open-source |
