説明

仕事の中で、コードのオンライン化はとても重要で、オンライン化人員として、流れに対して厳格に制御して、オンライン化コードの更新を必要とすることに対して注意深く研究する必要があります!!
継続的な納品に進む前に、オンライン品質を保証する前提の下で、どのようにオンライン効率を高め、自動化された配置を実現し、継続的に納品するかは、深く、持続的に注目すべき問題である.

コードオンラインプロセス

svnコード更新-->テスト環境オンラインテスト-->テストOK後、テスト結果を運次元にメールで通知し、オンラインコードsvn_revision-->オンラインになる前にsvn_を記録します.revisionは、前回のオンライン時の変更と比較して、各サービス接続に影響があるかどうかを判断し、プロファイルの修正に注意-->上司に報告する(オンラインが確定した後)-->オンラインはすべてのテストOKのすべてのコードを統一的にオンラインにする必要がある(事前にバックアップをしておくと、問題が発生しやすい.プロファイルの変動に注意し、更新後の各サービスが通じないことを防止する)-->オンライン後の機能をテストする(会社員にテストを行うように通知する)-->OKメールは全員に通知する.
注意:ラベル(svn tag)を付けるのはもっと一般的な方法です.

コード内の次元の操作に必要な構成

true,
    // 
    'user_avatar' =>[
        // ， 
        'default_avatar' => 'default.jpg',

    ],
    // 
    'broker_avatar' =>[
        // ， 
        'default_avatar' => 'default.jpg',
        // 

    ]
];

保持項目、keyとsvnの一貫性、対応する項目、keyの前後順序はsvnと同じであり、開発者、テスト者にとって、問題が発生した後に比較しやすい.運用次元では、対応するkeyのvalueを変更するだけで、線上の実際の状況に応じて変更できます.対応する注釈、項目、keyは勝手に修正したり、前後の順序を調整したりしないでください.調整が必要な場合はsvnで調整し、開発者と交流して確認する必要があります.
**オンラインで発生した問題**
次のエラーを避けるために、オンラインで発生した問題を列挙します.昨日オンラインに通知した後、まずsvnコードを更新し、svn_を記録します.flagの位置点は1392で、アップロードしたコードの人に間違いなく深刻な修正がないことを尋ねた後、コードのオンラインを更新し、初めてオンラインになったので、すべてのコードを一度にオンラインに配置し、完了した後、テストは問題ありません.レポートを終了します.
家に帰ると、会社の人は、問題が発生し、ログインできないと、apiログのアクセスログを見て、errorがあることを発見しましたが、処理結果がなく、翌日会社に行って解決を協議しました.
来たら、コードを作成する人に聞いて、apiログを見てerrorを発見した後、1つのプロファイルがまだ古いバージョンであることを発見して、チェックしてからコードを再オンラインにします.問題が解決される!
**原因の概要**
コードにはconfigディレクトリがあるので、オンラインになってから次元を運ぶにはconfigディレクトリの下で構成を変更し、mysqlとredisに接続する必要があります.だから、コードを上げる前に古いバージョンとこのディレクトリをバックアップして、新しいコードがオンラインになってから、configディレクトリを置き換えて、すべての構成は変わっていないと思っていました.
しかし、ログでapiインタフェース呼び出しエラーが見つかり、プロファイルに戻って発見されました.古いconfigディレクトリを置き換えましたが、このディレクトリの下でも更新されたので、オンラインで同期できませんでした.

エラーのまとめ

今回の誤りを通じて、問題の深刻性を認識し、もし今回の問題が正式な製品ラインで発生した場合、結果は深刻であるため、厳格に反省し、文書をまとめ、警戒を高め、今後同じ誤りが発生しないようにしなければならない.