Geekly Articles each Day

戦いに出る

戦いに！ 最終的なWeb製品の実装は、作成者にとって最も楽しい手順ではなく、ひどいストレスを伴うことがよくあります。 開発者のリリースに対する嫌悪は、責任感や新バージョンの悪用への恐怖だけでなく、不確実性の感情にも関連しています。導入後はどうなりますか？

プログラマー、品質エンジニア、グラフィックインターフェイスの大規模なチームがアプリケーションを開発できますが、プロジェクトの最後にモヒカン人が責任を負います。 理論的な知識の欠如は、試行錯誤の結果として得られた経験が実装を体系的に成功させるのに1時間では不十分であるため、ヒーローを緊張させます。 Webプロジェクトを適切に戦いに巻き込む方法を理解するために、基本から始めましょう。

一般スタッフプラン

開発ワークフロー

開発者は、要件、仕様、あらゆる種類の推奨事項および指示を受け取った後、ソースコードリポジトリ内の自分の操作用のスペースを割り当てます。 そのような領域は、個人のSVNブランチ、CVSの新しいモジュール、またはファイルシステム上のフォルダーです。

「開発-テスト-デプロイ」の後続のサイクルについて詳細に話すことは意味がありません。それらについて非常に多くの有用なことが書かれています。 重要な所見のみに注意してください。最終的な開発結果はリリース候補に記録され（ブランチのマージ、タグの作成など）、受け入れテストに転送されます。 リリース候補は、変更できない最終的なモノリシック製品です。 エラーを修正し、機能を変更する必要がある場合は、最初から始めて新しい候補を作成する必要があります。

学ぶのは難しい

多くのマネージャーが開発環境で受け入れテストを実施していることは注目に値しますが、これは根本的に間違っています。 ナノバッグの個別の候補を作成することは非常に怠けている（そして無駄である）ことは明らかです。 しかし、テストプラットフォームでの実装手順が完了すると、開発者の時間と神経が大幅に節約されます。 さらに、マイナーな修正をグループにグループ化して、製品の1つのバージョンで修正することに煩わされることはありません。

受け入れテストの重要なヒント：候補からリリースへの移行には、「候補-テスト-変更」という一定の反復回数がかかる場合があります。 サイクル中に、新しいバグが発見され、要件が変更され、変更が加えられます。 最終的に、悪循環を断ち切り、解放しなければなりません。 また、プレリリーステストレポートが完全に完成することは非常にまれです（そのような場合、開発者はベータプレフィックスで免除されます）。
私はかつて広告に関するポータルの開発を行っていました。 その後、チームはリリースを導入する前に20人までの候補者をロールアウトする必要がありました。 リリースは10回目から導入されました。 最終テストレポートは〜70％成功しました。 私の人生で最も成功したプロジェクトではありません。

武器へ

リリースの実装順序は次のとおりです。
  1. プラットフォームコンポーネントの新しいバージョンを紹介しています 。 古いバージョンにロールバックするツールを保持しながら、ライブラリ、サービスなどを更新します。
  2. データベースとファイルストレージを紹介します 。 アプリケーションの以前のバージョンがバトルで機能する場合は、新しいストレージ構造をサポートするために古いリリースを事前に準備する必要があります。 物語はこれです：
    • 以前のリリースに新しいストレージスキームのサポートを追加する
    • 変更された以前のリリースの紹介
    • 新しいストレージ構造を導入し、データを移行します（以前のリリースは新しいストレージの古いロジックで動作するはずです）
    • 新しいリリースの紹介
  3. アプリケーションを実装しています 。
  4. アプリケーションのテスト 。
  5. ロールバックします （必要な場合）。
fakapの場合、逆の順序で前のバージョンにロールバックします。
  1. アプリケーションをロールバックします 。
  2. データベースとファイルストレージをロールバックします （必要な場合）。
  3. プラットフォームコンポーネントのロールバック （必要な場合）。

戦闘への応用

まず、フォルダー構造がファイルストレージから分離されるように、アプリケーションを設計する必要があります。
そうだね
 / var / www / myproject /
	 /その他/
	 / lib /
	 /クラス/
	 /画像/
	 /テンプレート/
	 index.php
 / var / www / userdata /
	 /画像/
	 /ビデオ/
正しくない
 / var / www / myproject /
	 /その他/
	 / lib /
	 /クラス/
	 /画像/
	 /テンプレート/
	 /ユーザーデータ/
		 /画像/
		 /ビデオ/
	 index.php
第二に、サードパーティのライブラリバージョンを制御する必要があります。 サポートされているバージョンのZend Frameworkライブラリが確実にバトルで使用されるようにするには、ライブラリをアプリケーションのフォルダー構造に含める（およびsvnに保持する）か、リリースをパッケージとして提示して（たとえばdeb ）依存関係を確認する必要があります。

第三に、多くの開発者は、ソースコードリポジトリから更新することにより、アプリケーションを戦闘に導入します（ svn up ）。 このアプローチはrm –rf /としか比較できません。 リリースはリポジトリから完全に抽出され、以前のリリースとは別の場所に配置される必要があります。
リリースは、戦闘プラットフォーム上の別個のフォルダーに配置されます。
 user @ stable：〜/ apps / myproject $ ls -la
 drwxr-xr-x 12ユーザーwww-data 4096 Oct 29 11:38。
 drwxr-xr-x 5ユーザーwww-data 4096 May 13 23:22 ..
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 22 17:11 rel_0.5.1
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 27 13:17 rel_0.5.1.1
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 28 02:07 rel_0.5.1.2
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 29 11:38 rel_0.5.2
 user @ stable：〜/ apps / myproject $ svn co svn + ssh：//user@svn.myproject.ru/myproject/tags/rel_0.5.2.1
 ...
 user @ stable：〜/ apps / myproject $ ls -la
 drwxr-xr-x 12ユーザーwww-data 4096 Oct 29 11:38。
 drwxr-xr-x 5ユーザーwww-data 4096 May 13 23:22 ..
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 22 17:11 rel_0.5.1
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 27 13:17 rel_0.5.1.1
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 28 02:07 rel_0.5.1.2
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 29 11:38 rel_0.5.2
 drwxr-xr-x 8ユーザーwww-data 4096 Oct 29 12:31 rel_0.5.2.1
ソースコードを抽出した後、プロジェクトがインストールされ（構成、権限、開始データが構成されます）、作業リリースの隣でテストされます。これには、Webサーバーの別の仮想ホストを使用できます（たとえば、 www-test.myproject.ru ）。 テスト計画を実行した後、以前のリリースは新しいものに置き換えられます。 リリースを置き換えるための次のオプションが知られています：シンボリックリンクの変更、 mount_null 、ウェブサーバーの設定の変更、それに続くグレースフルリスタート 。
シンボリックリンクを使用して、プロジェクトをあるリリースから別のリリースに切り替えます。
同様に、以前のバージョンにロールバックできます。
 user @ stable：〜/ httpdocs / $ ls –la
 drwxr-xr-x 3ユーザーwww-data 4096 Oct 29 11:40。
 drwxr-xr-x 9ユーザーwww-data 4096 Oct 28 21:25 ..
 lrwxrwxrwx 1ユーザーwww-data Oct 27 29 11:40 pro-> ../apps/myproject/rel_0.5.2
 user @ stable：〜/ httpdocs / $ rm pro && ln –s ../apps/myproject/rel_0.5.2.1 pro
 user @ stable：〜/ httpdocs / $ ls –la
 drwxr-xr-x 3ユーザーwww-data 4096 Oct 29 11:40。
 drwxr-xr-x 9ユーザーwww-data 4096 Oct 28 21:25 ..
 lrwxrwxrwx 1ユーザーwww-data Oct 27 30 17:12 pro-> ../apps/myproject/rel_0.5.2.1
アプリケーションが配布されている場合：より多くのサーバーが関与し、アプリケーション構造が複雑になるほど、より多くの自動化ツールと監視ツールが必要になります。 ただし、未来学者のお気に入りのルールを忘れないでください。ロボットを信用しないでください-ロボットは間違いを犯しがちな人によって作成されました。
PSストーリーを完成させるのに十分な力があれば、 LiquiBaseの楽しさ 、rsyncの落とし穴、ファイルストレージの移行についての第2部を待ちます。
PPS habrayuzerの1つとの通信中に、それが定式化されました。この情報アピールの主なことは、私の推奨事項を課すことではなく、特定の状況で発生する可能性のある問題について考えさせることです。 * ^に関する一般的な推奨事項と、誰も必要としません。 最終的には、誰もが自分のやり方でそれを行います。 そして、そうです。 すべてのプロジェクトはユニークだからです。

Source: https://habr.com/ru/post/J43643/

More articles:


All Articles