コードの後に​​生命はありますか？

コードが記述された後、コードはどうなりますか？ ソフトウェア開発の多くの分野で、彼の人生はまだ始まったばかりです。 たとえば、Web用の開発では、アプリケーションはサーバー上のどこかで実行されます。 したがって、コードを記述した後、タスクはそれをアプリケーションに統合し、最終的なマシンに配信することです。 これが今日説明するプロセスです。



このテキストは、幅広い開発者を対象としており、コードのレイアウトプロセスを初めて使用する人向けに設計されています。 また、このテキストは、展開システムを構築しており、アイデアを探している人に役立つ場合があります。



この記事は、アオリの社内セミナーの資料に基づいて書かれており、私たちが構築したプロセスの例を使用して、展開の原則について説明しています。

展開はどのように始まりますか？

最も一般的な近似では、コードを記述した後、1つの固有のタスクがあります-書かれたものをそれが起動される場所に送信することです。 つまり、大まかに言えば、ftpまたはssh経由でアップロードします。

ftpでシールに関するサイトの更新をアップロードする場合、これも展開です。



今日、シールはありませんが、コンソールであるLinuxがあり、ssh経由ですべてをアップロードしています。 したがって、展開プロセスは次のようになります。

1. プロジェクトをアーカイブにパックする
2. ssh経由でリモートマシンに送信する
3. Webサーバーがマウントされているフォルダーで解凍します。

ニュアンスがあります

リモートサーバーでプロジェクトを展開すると、実際にはフォルダーの内容が新しいもので上書きされます。 良い方法では、最初にフォルダをきれいにする必要があります。 ただし、計算中のサービスは利用できなくなります。



また、エラーが発生してプロジェクトを展開した場合はどうしますか？ ローカルバージョンをロールバックし、アーカイブをいっぱいにしてすべての操作を再実行する必要があり、急いで台無しになる可能性が高くなります。



これらの問題に対する非常に簡単な解決策があります-計算は新しいフォルダーで毎回行われ、同じ名前のシンボリックリンクが毎回切り替わります：

1. リモートマシンでは、バージョンなどのsshを操作するユーザーのホームフォルダーにディレクトリが作成されます。 ビルドごとに、バージョンごとにサブディレクトリを作成し、そこにプロジェクトを展開します。
2. その後、このフォルダーへのシンボリックリンクを名前、たとえば、カレントで作成します。 私たちのウェブサーバーはこのシンボリックリンクを見ています。 したがって、プロジェクトの切り替えは、単にシンボリックリンクを切り替えるだけです。

ln -nsf /home/project/versions/{0} /home/project/current
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サブディレクトリのバージョンは、計算手順のシーケンス番号によって便利に呼び出されます。

そしてもう一つのニュアンス

ほとんどの場合、リモートマシンの設定には独自の設定が必要です。 つまり、プロジェクトをパックする前に、戦闘構成をロールアップする必要があります。



さて、いくつかのステップで計算中にエラーが発生した場合、計算を停止する必要があります。



プロジェクトをリモートマシンにレイアウトするために必要な最小限の手順は次のとおりであることがわかります。

1. 戦闘設定をロールアップする
2. プロジェクトをパックする
3. プロジェクトをリモートマシンにアップロードする
4. 新しいフォルダーに解凍する
5. シンボリックリンクを切り替える

いずれかのステップでエラーが発生した場合は、停止します。

自動化

これらのタスクを手動で実行しないでください。計算のために実行するbashスクリプトのような何らかの自動化が必要です。

NB原則として、bashスクリプトで十分です。



アオリでは、最終的な展開にFabricを使用しています。 これは、上記の問題を非常に簡単な方法で解決できるPythonライブラリです。



アメニティの中では、いわゆる役割-すべてのマシンではなく、一部のマシンでのみいくつかの展開項目を実行できるマシンの名前付きグループに言及したいと思います。 戦闘環境には、静的、Webアプリケーション、およびスクリプトの3つの役割があるとしましょう。 したがって、静的なマシンでのキャッシュのウォームアップは不要であり、crontabはスクリプトマシンでのみ更新する必要があります。



例として、ファクトリスクリプトの一部を次に示します。

 @parallel @roles('web', 'script', 'static') def switch(id): run('ln -nsf /home/project/versions/{0} /home/project/current'.format(id)) @roles('script') def crontab(id): run('crontab /home/project/versions/{0}/build/crontab'.format(id)) @parallel @roles('web', 'script', 'static') def clear(id): with cd('/home/project/versions'): run("ls -1 | grep -E '^[0-9]+$' | sort -n | head -n -3 | xargs -rt rm -rf") def deploy(id): execute(prepare) execute(upload) execute(upload_static, id) execute(build, id) execute(migrate, id) execute(switch, id) execute(crontab, id) execute(clear, id)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

gitを忘れないでください

ブランチを使用する場合、少なくとも本番環境に送信する準備ができているコードのマスターがあり、すべてをコミットする開発がテストされ、安定するにつれてマスターに注がれます。



この場合、開発もどこかに配置されており、独自の個別のファクトリスクリプトが必要です。

そしてユニットテストについて

コードをどこかに送信する前に、明らかに打たれたコードをレイアウトすることは意味がないので、テストを実行する必要があります。



そのため、コードをレイアウトするためのアクションのリストが増えています。

1. 計算用のブランチを設定します。
2. このブランチのビルド番号を設定します
3. 共有リポジトリからこのブランチへの変更をプルします
4. ドライブユニットテスト
5. このスレッドの構成をプル
6. プロジェクトをパックする
7. このブランチに対応するリモートマシンに注ぐ
8. 新しいフォルダーに解凍する
9. シンボリックリンクを切り替える

いずれかの段階でエラーが発生した場合は、停止します。



さて、私たちはすべてを賢くやっているので、

1. 開発者は本番マシンでsshにアクセスしてはいけません
2. 開発者は本番環境の構成にアクセスするべきではありません
3. テストアプリケーションが常にテストに利用できるように、展開ブランチはコミットの直後に展開する必要があります。
4. 計算中にエラーが発生した場合、開発者はメールにレターをドロップする必要があります。

これらのすべてのアクションを手で実行するためには、ファクトリスクリプトのセットを持っていても考えられないため、別のツールが必要なようです。

別のツール

私たちを支援するツールはContinuous Integration Serverと呼ばれ、実際、コマンド、スケジュール、または外部イベントに従って指定されたリポジトリの新しいコードを取り出し、リストされたコマンドのセットを実行します。 JenkinsをCIのツールとして使用します。



上記のタスクを継続的に統合するサーバーは、アセンブリカウンターのインクリメントと失敗した場合のレターの送信のみを実行できることを理解することが重要です。 単体テスト、ロールバック設定、その他の便利な機能を実行するには、bashスクリプトの高度な機能を実行する別のツールが必要です。

個別のビルドスクリプト

工場を展開に使用した場合、プロジェクトを構築するタスクにはPhingを使用します 。 第一に、それは便利であり、第二に、ジェンキンスはそれとうまく統合します、そして、3で、それは歴史的に起こりました。



指が解決するタスクの例を次に示します。

phing build



プロジェクトをビルドします

phing gerrit-phpcs



コード標準の確認

phing copy-production-configs



閉じたリポジトリから本番マシンの構成を取得します

phing write-version



現在のアセンブリのタイムスタンプファイルを保存します。



そして、開発ブランチからテストサーバーへのコードの完全なパスを次に示します。



指が最初に動作します。 すべてのアクションは、ローカルのJenkinsフォルダーで発生します。

1. チェックアウトブランチの作成
2. 最後に成功したビルドとこのビルドの間の変更を確認します（最後に成功したビルドのsha、および他の多くの有用な情報は、Jenkins apiおよびJenkins変数を通じて取得できます ）。
3. 変更がjsアプリケーションのみに関係する場合、単体テストは実行しません
4. そうでない場合は、一意の名前で空のテストベースを作成します。 これにより、アセンブリを並行して実行できます。
5. 移行をロールバックします。 ベースの構造とその変更を移行の形で保持します
6. テストを実行する
7. ベースを削除
8. 構成をロールします
9. 現在のアセンブリのタイムスタンプを書き込みます。 これは、キャッシュを無効にするために必要です。
10. 工場を立ち上げる

工場は、コードをエンドマシンに送信する責任があります。 アクションのシーケンスは次のとおりです。

1. プロジェクトをパックします
2. 私たちは車にレイアウトします
3. 移行を開始します
4. シンボリックリンクを切り替える
5. crontabの更新
6. 最後の3つを除く古いバージョンを削除する

Codreview

結論として、コード検査のソリューションについてお話したいと思います。



最も単純な形式では、従業員の肩越しにレビューを実施し、口頭でコメントすることができます。 開発者がコミットした内容を確認し、チケットにコメントを書くこともできます。 原則として、これで十分な場合もありますが、検査プロセスを簡素化し、自動チェックと組み合わせる特別なツールがあります。



開発ではGerritを使用します。



gerritの主な利点は、gitと密接に統合され、実際にはgitサーバーになることです。 その後、GerritのWebインターフェイスを介して、実際の監査を実行できるだけでなく、gitに対する権限を管理することもできます。 したがって、通常の開発者は開発やマスターに直接プッシュする権利がなく、変更をレビュー用に送信してスクリプトを実行することしかできません。 git review

NB , , - , . , , submit , git review.



-. , : " , " . - .





, - . , github . , , , - , , , .





Jenkins - Wikipedia

Jenkins + Python -

Gerrit - Wikipedia

Gerrit -

Fabric -

Fabric

Phing -

Phing

Continuous Integration - Wikipedia

git review

NB , , - , . , , submit , git review.



-. , : " , " . - .





, - . , github . , , , - , , , .





Jenkins - Wikipedia

Jenkins + Python -

Gerrit - Wikipedia

Gerrit -

Fabric -

Fabric

Phing -

Phing

Continuous Integration - Wikipedia

git review

NB , , - , . , , submit , git review.



-. , : " , " . - .





, - . , github . , , , - , , , .





Jenkins - Wikipedia

Jenkins + Python -

Gerrit - Wikipedia

Gerrit -

Fabric -

Fabric

Phing -

Phing

Continuous Integration - Wikipedia

git review

NB , , - , . , , submit , git review.



-. , : " , " . - .





, - . , github . , , , - , , , .





Jenkins - Wikipedia

Jenkins + Python -

Gerrit - Wikipedia

Gerrit -

Fabric -

Fabric

Phing -

Phing

Continuous Integration - Wikipedia

git review

NB , , - , . , , submit , git review.



-. , : " , " . - .





, - . , github . , , , - , , , .





Jenkins - Wikipedia

Jenkins + Python -

Gerrit - Wikipedia

Gerrit -

Fabric -

Fabric

Phing -

Phing

Continuous Integration - Wikipedia