今日、主なグループは、ツール 自動展開のうち、オープンソースだけで、readmeの機能は、非常に詳細に導入されている、この記事は、環境、いくつかの意思決定の考慮事項によって生成された状況の周辺を紹介するだけです。
しょ
自動化されたファブリックファイルと、モバイルSohuの開発を担当するためにSohuに入社したばかりだったという事実から、物事は始めなければなりません。私が捜狐に入社したとき、プロジェクトのデプロイはすでに自動化されていましたが、ツールに抽象化されてはいませんでした。当時、2つのプロジェクトによって、1つはtornadoベース、もう1つはDjangoベースで、2つのプロジェクトは独自のリリース方法を持っていますが、ロジックは基本的に同じです。
両方のプロジェクトの稼働プロセスは、まずパッケージ化し、supervisordによって起動・管理される内部のpypiserverを介して個々のサーバーにインストールします。
事業の発展に伴い、新しいプロジェクトの数も徐々に増えてきました。この時、新しいプロジェクトの開発プロセスはこんな感じです：まずfabfileとsupervisordの設定ファイルとsetup.pyファイルをプロジェクトにコピーし、次にソースコードを記入します。このプロセスはまだ同じです。
秩序がなく、混沌としていました。
ライブラリーの構築を開始します。
とはいえ、プログラマーはみんな怠け者です。このコピーは、多かれ少なかれ、自分自身を少し不寛容にさせるので、 、我々はこのようなライブラリを構築することを提案し、すべてのプロジェクトは、この上にロールアップすることができます。というわけで、ライブラリ構築のタスクが私に与えられました。
ジェネリック・ライブラリを構築するためには、プロジェクトで使われているパーツを抽象化する必要があります。たまたまその間、私はバグフィックス、パッケージ化、そしてパッケージ化されたスクリプトやコンフィギュレーションファイルのコピーなど、オンラインでのデプロイ作業にも携わっていました。
以上の経験を生かして、必要なものを出力するだけ。要約すると、当時、プロジェクトのパッケージングと立ち上げには次のような側面がありました：：。
1. パッケージング -- バージョン番号を生成し、セットアップでバージョンとプロジェクト情報をレンダリングし、pypiサーバーのpackagesディレクトリに置く。
2. 仮想環境 - 新しいサーバーに仮想環境を作る
3. プロジェクトのインストール - pypiserverからプロジェクトを仮想環境にインストールする。
4. supervisordの起動 - プロジェクトのプロセスを管理する
5. nginxのコンフィギュレーションを切り替える - オンラインで同時に稼働している環境は2つあり、それは環境aと環境bと呼ばれる。
よくわからない場合は、エッセイの説明を確認してください。つまり、これらの機能さえ満たせば、ライブラリーは完成です。さらに、新しいプロジェクトの開発を容易にするためには、これらの機能を備えたプロジェクトテンプレートを自動的に作成できるようにする必要もあります。実はここが一番の悩みどころで、いつも一番不得手なものをコピーしてしまうのです。
プロジェクトの作成、テンプレートの初期化、gitlabやgithubへの初期化を追加しました。
プロジェクトの開発や配備、自宅での移動に最適なツールです。
競合
需要が明確になった後、どのようにプロジェクトのコードを整理するのですか？ 通常のWebプロジェクトでは、難しくはありません、固定テンプレートがあります。このようなツールの場合、あるいは **** 検討する時間は、より合理的に設計する方法 - 拡張しやすく、保守しやすい - です。長い間 django のソースコードをひっくり返した後、私はコアのアイデアに従うようになりました。
コード構造の議論は、経験に基づいてどちらが優れているかわかります。ソフトウェア開発に特効薬がないように、ビジネスシナリオはそれぞれ異なり、統一された解決策はありません。
もう一つの論点は、デプロイ方法です。ドキュメントを読んだことがある人、あるいは上記のデプロイ方法をすでに理解している人は、こう思ったかもしれません。なぜgitでデプロイしないの？タグ付けとかもあるし。"と思ったかもしれません。 それは検討中のことです。
ひとつはgitを使ってコードをデプロイする道、もうひとつはpip install project packagesを使ってデプロイする道でした。後者を選びました。理由はこうです：
1.歴史的理由- プロジェクトは常にこの方法で行われてきました。
2.サーバー構成のコスト - 私はこれが最も重要だと思いますが、2つの方法、gitのデプロイメント、サーバーのgit環境のインストールを統一するために比較すると、新しいサーバーへのアプリケーションは、この事を持っていない、あなたは自分自身をインストールする必要があります。また、インストールにpipを使用し、余分な処理を行う必要はありませんが、新しいマシンは、ipを与え、直接上に展開することができます。
冒頭の開放性
以上のようなプロセスを経て、エッセイというツールが生まれました。プロジェクト終了後、後日さまざまなグループに分かれ、新しいプロジェクトを担当するようになりました。このツールはプロジェクトの発展において重要な役割を果たしてきました。このツールは、過去1年ほどの開発・配備の経験をまとめたもので、開発者にとってもチームにとっても、公開することに価値があるはずだと思います。
私自身、このツールの開発中に多くのことを学びました。開発からデプロイまでのプロジェクトの全プロセスを理解しようとする熱心な開発者なら、誰でもこのツールの恩恵を受けることができるはずです。
オープンの目的は経験を共有することだけでなく、コミュニケーションという重要な機能も果たします。業界で蓄積された経験は必ずしも****ではなく、より多くの、より良いソリューションがあるはずで、これらは交換から生まれるはずです。これはお互いを促進することができ、相互促進はオープンとオープンソースの本来の目的です。
:
追加データ
モバイルSohu(m.sohu.com)は毎日数億PVがあり、このような場合、オンラインバグの発見は、一般的に、バグ修正からオンラインまで15分以上かかることはありません。また、オンライン時にページへのアクセスが遅い、開けないということもありません。新機能やバグの場合、1日に10以上のバージョンをオンラインにすることも可能です。オンライン各時間は、環境のa、bの2つのセットの展開への鍵は、ユーザーに影響を与えません。
私がモバイルSohu.comの開発に携わっていた頃、バックグラウンドには100台以上の仮想マシンがあり、ホットなイベントが発生すると倍増するようになっていました。この場合、新機能をオンラインにするプロセスは、私が覚えている限りでは5分もかかりませんでした。ファブリックの成功のコンソール出力をオフにして並列モードをオンにすれば、リリースはさらに速くなったでしょう。
