Webプロジェクト開発インフラストラクチャとライフサイクル

プロジェクトが小さい場合、特別な問題はありません。 タスクのリストはテキストファイル（TODO）に保持でき、バージョン管理システムは概して省略できます。それらを単純に（cp / scp / rsync）ファイルにコピーしてライブサーバーにアップロードし、常にエラーを確認できます。ログファイル内。 たとえば、2つのスクリプトと1日あたり3人の訪問者を持つ単純なサービスでは、本格的なサーバー構成管理システムを構築するのは愚かなことです。



プロジェクトが拡大するにつれて、要件も増大します。 TODOファイルに多数のタスクとバグを保持するのは不便になります。優先順位、コメント、リンクが必要です。 バージョン管理システム、サーバーにコードを展開するための特別なスクリプト/システム、および監視システムが必要です。 複数の人がプロジェクトに取り組むと状況が悪化し、プロジェクトが複数のサーバーに成長すると、本格的なインフラストラクチャが出現します（「システムの機能の基礎となる、相互接続されたサービス構造またはオブジェクトの複合体」、Wikipedia）。



Mail.ruカレンダーサービスの例を使用して、典型的なインフラストラクチャと、大規模なインターネット企業で中規模のWebプロジェクトを開発するライフサイクルについて説明します。





すべての作業は、計画された機能であろうとエラーメッセージであろうと、問題のステートメントから始まります。

プロジェクトおよびタスク管理

システム「Issue＆project tracking」として、Mail.ruでは、 Atlassian Jiraを使用します。これは、大規模な組織の事実上の標準です。 Jiraを使用している企業の完全なリストにはほど遠いです： en.wikipedia.org/wiki/Atlassian_JIRA このシステムには同等の機能、柔軟性、拡張性、使いやすさはありません。利用可能な情報によると、数千人の従業員を抱える最大規模のIT企業の一部は（保証によると） Bugzillaをバグトラッカーとして使用しています。



小さなチームやプロジェクトの場合、同じBugzilla 、 Phabricator 、 Redmineのような洗練されていない、 より無料のアナログを使用することをお勧めします。 または、プロジェクトホスティング（ GitHub 、 BitBucketなど）を使用している場合、それらに組み込まれているエラー追跡システムを使用できます。

現在、Jiraのカレンダープロジェクトには1816個のタスクが含まれており、そのうち1386個が正常に閉じられています。 そのうちの約500個はバグでした=）

マネージャー、テストスペシャリスト、またはユーザーサポートサービスによってタスクが設定された後、開発者は作業を進めます。 すべてのプロジェクトコードはリポジトリにあります。

バージョン管理システム

これまで、最も一般的なバージョン管理システムはGitとMercurialです。 両者は、詳細は異なりますが、おおむね類似した機能（分散システム）を備えています。 ほとんどすべてのMail.ruプロジェクトはGit（一部はSVN、一部はCVSを含む）に切り替えられ、Calendarも例外ではありません。



当社には、gitリポジトリをホストするためにgitosisがインストールされたいくつかの大規模で強力なサーバーがあります。 リポジトリごとに設定が異なります。たとえば、開発者はPEP8標準に準拠していないカレンダーリポジトリにPythonコードをプッシュすることはできません（これにはサーバー上の特別なフックが続きます）。



すべてのカレンダーコード（フロントエンドとバックエンド）は1つのリポジトリに保存されます。 これにより、中小規模のプロジェクトの場合、プロジェクト全体をすばやく展開し、コードの変更を簡単に追跡できます。 大規模および非常に大規模なプロジェクト（Mail.ru Mailなど）の場合、クライアントコードとサーバーコードを別々のリポジトリ（または複数）に保存する方が便利ですが、もちろん、どのアプローチでも意味のある合理的な判断が必要です。

現在までに、Calendarリポジトリには7175のコミットがあり、常に約300のブランチが作成されています。 プロジェクト全体のサイズは60 MBです。

プロジェクトを開発するには、最初にプロジェクトを開始する必要があります。そのためには、適切なソフトウェアとライブラリが必要です。

開発環境

すべての安全規則は血で書かれていると言われています。 もちろん、IT企業ではこれは実現しませんが、それでも厳しいルールがあります。 たとえば、Mail.ruでは、システム管理者のみが「バトル」サーバーと実際のユーザーのデータにアクセスできます。 開発者は、「ライブ」に接続されていないテストユーザーを含むテストマシンのみを使用でき、すべての開発はテストネットワークでのみ実行されます。 この職務の分離により、最も「賢い」プログラマーは「すぐに生計を立てる」という誘惑から解放され、コードをより思慮深く正確に書くことができます。



同じマシンで実行するのが非常に難しく、時には不可能なシステムがあります。たとえば、Mail.Ru Mail：本格的な操作には、膨大な数のライブラリ、デーモン、スクリプト、サービスが必要です。 このようなプロジェクトは、テストネットワーク上の複数（数十）の仮想サーバーで実行され、開発者はこれらのマシン（vim、emacs、diffなど）で実行されるコードを操作します。



カレンダーでは幸運でした。プロジェクト全体が開発者のローカルマシンで非常に簡単に実行され、開発に問題はありません。 仕事には、お気に入りのエディター、IDE、およびデバッガーをトリックなしで使用できます。各プログラマーは自分のコードで作業し、他のユーザーの作業には一切影響しません。 もちろん、開発ネットワークにも仮想サーバーがありますが、主にテストに使用されます。 カレンダー上の全員が仕事でMacBookを使用することを好むという事実により、作業がさらに簡単になり、開発環境はチームメンバーにとって実質的に同じになります。



カレンダーのサーバー側はPythonで記述されており、もちろん、システムの開発とデプロイにはvirtualenvを使用しているため、コマンドを実行するだけで必要なすべてのライブラリをインストールできます。

  pip install -r requirements / development.txt 

クローンリポジトリから。 クライアント（フロントエンド）部分はnpmを使用し、すべての依存関係は同じように簡単かつ自然にインストールされます。

カレンダーは現在33のサードパーティPythonライブラリを使用しています。

ポピーに必要なすべてのソフトウェアはbrewからインストールされ、開発者のコ​​ンピューターにプロジェクトを最初にインストールする場合は、実行するだけです

  brew install ... 

依存関係のリスト。 もちろん、1つのコマンドでは不十分であり、たとえばPostgreSQLでのユーザーとデータベースの初期化など、さらなる設定が必要になります。 個々のプログラムのインストールにはいくつかの機能がありますが（たとえば、モジュールにパッチを適用したnginxを使用します）、ドキュメントシステム（wiki）にすべてが記載されているため、これは問題を引き起こしません。

プロジェクト文書

知識は力です。 知識は同僚と共有する価値があり、同僚は自分自身を忘れないように記録する必要があります。 Wikiシステムは情報を保存するのに理想的な場所です。Mail.ruでは、 Atlassian Confluenceをそのまま使用しています。 Confluenceの他のwikiシステムに比べて特別な利点はありませんが（実際、それらの機能は似ています）、アトラシアン製品が当社に定着し、人気を博しました。 1つの利点はまだありますが、ある会社の製品は簡単に相互に統合でき、大企業ではすべての内部サービスが何らかの形で相互に接続されます。



開発および運用プロセスに関連するすべての文書化を試みます：このソフトウェアまたはそのソフトウェアのインストール方法、必要な構成、発生する可能性のある問題、実行しているサーバー、サービスの相互通信方法。

Confluenceのカレンダープロジェクトには、122のドキュメントページがあります。

すべての製品には品質管理が必要であり、当社のカレンダーも例外ではありません。

コードレビュー

各開発者はコードのエラーに直面しています。 品質をめぐる闘争の最初のステップはコードレビューです。これにより、プログラムの欠陥にタイムリーに気付くことができます。 コード監査のもう1つの利点は、各コミットで少なくとも2人のプログラマーに精通していることです。コードを作成したプログラマーとレビューしたプログラマーです（それぞれ、責任も半分に分けられます）。



Atlassianにはコードレビュー用の素晴らしいるツールがありますが、カレンダーでPhabricator（ Facebookからのオープンソース開発）を使用することが起こりました。 ファブリケーターには多くの機能がありますが、その一部、つまり監査、コードのコメント、オンラインリポジトリの表示のみを使用します。

平均して、コミットの監査ごとに、3〜4つのコメントが表示されます。

同僚のコメントを修正した後、コードは品質管理の次の段階に進みます。

解析とテスト

美しいコードは良いコードです。 すべてのチームメンバーがコードスタイルのルールに従うことで、プログラムのどこでも一目で理解できるようになり、また、大多数の愚かな間違いを回避できます。 カレンダーリポジトリへの各プッシュは、 PEP8 、 pyflake 、およびpylintを使用してチェックされます。

カレンダーのpep8およびpyflakeルールに例外はありません。

良いコードは動作するコードです。 私たちはプログラムが機能するときが大好きで、プログラムが壊れているときは好きではありません。 賢い人たちはさまざまな種類のテスト（単体テスト、機能テスト、回帰テスト）を考え出しました。これらの開発を喜んで使用します。

これまでに、プロジェクトには580の自動テストがあります。

さまざまなタスクを実行するには、オープンソースのJenkins CI （継続的インテグレーション）システムを使用します。このシステムには、カレンダーに3つのタスクがあります。

1. テストブランチの場合：コードの構文制御（lint）、すべてのテストの起動、コードカバレッジレポートの準備
2. プレリリースブランチの場合：コードの構文制御（lint）、すべてのテストの起動、プロジェクトのテストパッケージ（RPM）のアセンブリおよびプレリリース（テスト）サーバーでのレイアウト
3. マスターブランチの場合：テストの実行とプロジェクトパッケージ（RPM）のビルド

すべてのタスクは、対応するブランチがgitリポジトリのフックによってプッシュされると起動されます。

プロジェクトの組み立てには、平均で約5分かかります。

自動テストは優れていますが、ソウルレスマシンは人間の心と創意に代わるものではありません。 ライブテスターが助けになります。 各リリース（およびカレンダープロジェクトのリリースは、平均して2週間に1回行われます）は、テスターに​​よってプレリリースサーバーでチェックされます。 彼らは、先週実装された新しい機能に特に注意を払い、プロジェクトの重要な機能をテストします。



出力は、virtualenv、必要なすべての依存関係（ライブラリ）、およびファイル（静的）を含むプロジェクト全体を含む1つ（またはプロジェクトに応じて複数の）RPMファイルです。



リリースは組み立てられ、テストされ、検証され、軍用車両にアップロードする準備ができており、システム管理者のみがアクセスできます。

戦闘中のプロジェクトのレイアウト

管理者は賢く怠け者です。 日常的な操作を頻繁に行う必要がある場合は、自動化してみませんか？



Mail.ruには何千ものサーバーがあり、それぞれに独自の役割と独自の設定があります。 Puppetを使用してサーバー構成を管理します。 各サーバーグループの設定は、バージョン管理システムにある単純なファイルに記述されています。 したがって、構成ファイルへの変更の履歴は常に存在し、以前の状態のいずれかにロールバックできます。 システム管理者のみがリポジトリおよびパペット全体にアクセスできます。



新しいイテレーションをライブサーバーにアップロードするプロセスは、たとえば次のようになります。管理者は、必要に応じてプロジェクト構成ファイルを編集し、RPMパッケージの必要なバージョンを書き込み、変更をリポジトリにプッシュします。 次に、Puppetはすべてを処理します。すべてのサーバー上のすべての構成ファイルが更新され、パッケージがインストールされ、必要なサービスが再起動されます。

プロジェクトのレイアウトには約1分かかります。

コードは実稼働環境でレイアウトされているため、リラックスしてリラックスできるように思えますが、これは価値がありません。 もちろん、テスターは非常に賢くて風変わりであり、開発者が気づいていないエラーを見つけることもありますが、実際のユーザーはテスターに​​100の確率を与えます。 プロジェクトのステータスを監視できる必要があります。

エラーログ

まず、いわゆる「500」、つまりサーバー上の重大なエラーに関心があります。 それらが発生している場合（発生した場合は回避できない）、何か問題が発生したため、バグ修正を早急に準備する必要があります。 そのようなエラーをキャッチする方法は？ もちろん、すべてをログに書き込むことができます。その後、単純な「grep」を使用して（ログファイルを検索することで）エラーの数と種類を常に最新に保ちますが、より良いオプションがあります。



カレンダーのロギングシステムは、すべてのエラー、例外、および単純な警告をSentryという特別なシステムに送信するように構成されています。 その中には、エラーの統計（いつ、どのエラー、何回発生したか）だけでなく、これらのエラーに関する詳細情報も表示されます：各関数のコンテキスト内のすべての変数の値を含む完全なトレースバック（関数呼び出しの順序）。 ユーザーに関する情報（電子メール、OS、ブラウザー）および要求（URL、ヘッダー、GETおよびPOSTパラメーター）もあります。 ブラウザのエラーもすべてSentryに分類されますが、情報はそれほど詳細ではありません（JavaScript、何もする必要はありません）。 これにより、問題をローカライズし、エラーをできるだけ早く修正することが容易になります。



基本的に、Sentryにはさまざまな警告を記述します。 たとえば、リファクタリング中、関数を破棄する前に、常に警告を追加します。次の反復で、Sentryにメッセージがない場合にのみ、この関数はコードから完全に削除されます。 もちろん、間違いがあり、多くの間違いがあります（ "fakapy"）。

セントリーカレンダーは、1時間あたり平均約100件のメッセージを受け取ります。 Sentryは、毎分数千のエラーに耐えることができます（現場での実績=）。

ロギングは優れていますが、これは十分ではなく、プロジェクトの重要な統計です。

統計とグラフ

誰もが統計が大好きです。 マネージャーはそれを賞賛し、ヒット数とユーザー数の増加を喜んで、開発者はプロジェクトの「健康」に関する情報を受け取ります。 メトリックを収集および保存するためのシステムとしてGraphiteを使用します。また、 StatsD-着信メトリックを処理および集計し、保存のために同じグラファイトに転送するサーバーを使用します。



グラフィックスの目的は何ですか？ 既に述べたように、プロジェクトのステータスはグラフからいつでも判断できます：リダイレクトの数が突然増加した、データベースを照会する平均時間が2倍になった、またはサーバーの1つでのI / O操作の数が増加しました。 これにより、問題を検出することができます。また、履歴の存在（グラフィックは数か月から数年保存されます）により、プロジェクトの突然のトラブルの分析が容易になります。



チャートはリファクタリングに役立ちます。 たとえば、プロファイリング中に質問を引き起こした関数に統計デコレーターを追加し、負荷がかかっているコードの動作に関する信頼できる情報を取得するだけで十分です。 反復を編集してレイアウトした後、その有効性を評価できるため、関数が動作する平均時間を数百（数百から数十または数ミリ秒）に減らすか、データベースへのクエリの数を数百（数千）から他の単語よりも少なくすることで、リファクタリングの有効性が証明されます。



サーバーパフォーマンスグラフ（このためにDiamondを使用）により、負荷をタイムリーに評価し、追加のマシンを事前注文したり、プログラムのパフォーマンスに参加したりできます。

カレンダーのグラファイトには、毎分約25,000の異なるメトリックが書き込まれます。

すべてのプロジェクトは、ログ用ではなく、グラフ用にも書かれていません。愛するユーザーのために、人々のために書かれています。 また、ユーザーはプロジェクトに不満を感じることがあります。

ユーザーとのコミュニケーション

カレンダーには、人々が積極的に使用するフィードバックフォームがあります。 基本的に、これらは通知されたエラーに関するメッセージ、この機能またはその機能の実装のリクエスト、または素晴らしいサービスに対する感謝の言葉です。 これらの手紙はユーザーサポートサービス（ OTRSと呼ばれるユーザーレターを処理する特別なシステムを使用）に送られ、私たち、つまりプロジェクトの開発者にも複製されます。 これにより、常にすべての問題を認識し、迅速に対応することができます。困難なケースでは、私たちは執筆した人々に答え、彼らと一緒に生じた困難を解決します。



ユーザーの1人が、カレンダーに必要な機能を追加するように求める手紙を書いた（私が間違っていなかった場合、それはSMS通知に関するものだった）ことを思い出しました。 リクエストの15分後、ユーザーはあなたがリクエストしたとおりにすべてを行ったという回答を受け取りました。 彼の驚きは際限がなかった。

1日に約10件のメッセージを受け取ります。 それらの半分は感謝と肯定的なフィードバックの言葉です。

あとがきの代わりに

カレンダーをゼロから開発するプロセスは1年半しか続かず、カレンダーは1年弱前にリリースされました。 プロジェクトは若く、私たち開発者は絶えずインフラストラクチャを改善しています。 今後の計画について少しお話しします。



開発中にVagrantを使用してみてください。これにより、開発環境をさらに迅速かつ簡単に展開できます。 プロジェクト（Webバージョンとモバイルクライアント）の自動テストにSeleniumを試してみたい。 新機能のより良いテストのために、たとえば会社の従業員または特定の割合のユーザーのみのために、基準によってそれを含める十分な機会がありません。これのためにオープンソースのGargoyleプロジェクトを試してみたいです。 近い将来、当社の他のPythonプロジェクトの例に従って、チームはArcanist（プロジェクトリポジトリのコマンドラインからPhabricatorを操作するためのgitアドイン）を実装します。 これにより、コードレビュープロセスがさらに簡素化され、開発が容易になります。



開発プロセス全体を試してみましたが、ほんの一部に触れました。 プロジェクト開発は複雑なプロセスですが、大企業がアクセスできるすべてのリソースのおかげで、非常に興味深く魅力的です。 興味のあるコメントで質問することをお勧めします。それらに答えようとします。



ウラジミール・ルドニク、

Mail.Ruカレンダーのテクニカルディレクター