ファイルごとにプロジェクトを手動でサーバーにデプロイするのがベストプラクティスですか?


26

私が今働いている会社は、継続的デリバリーをまだ実装していません。ファイルごとにサーバーにプロジェクトを手動でデプロイします。ベストプラクティスは次のとおりです。展開ごとに1つのプロジェクトアーティファクトを手動で展開するか、ファイルごとの展開を続けますか?


12
このタスクのための「すべての状況に対する1つのプラクティス」は、リモートでもありません。
whatsisname

26
通常、「ベストプラクティス」に関する質問をするのはなぜ悪いのでしょうか。これは最悪の慣行であることに全員が同意できると思います。「サーバーに火をつける」より少し上にランクされます。


9
彼はすでに答えを知っているので、OPはこの質問をしていると思うし、彼の職場はDoing It Wrong(tm)であり、OPは物事のやり方を変えることを主張する証拠を集めようとしているのだと思う。
user1936

2
第二千年紀にこのようにしてやった。大丈夫です!;)
ドンブランソン

回答:


103

どちらがベストプラクティスですか?デプロイメントごとに1つのプロジェクト成果物を手動でデプロイするか、ファイルごとにファイルをデプロイし続けますか?

どちらでもない。

ベストプラクティスは、展開を完全かつ排他的に自動化することです。つまり、誰も手動でサーバーに何かを置くことできません

「要約の要約を要約する:人々は問題です。」(ダグラス・アダムス)

人々は間違いを犯します。コピーするのを忘れたファイルの1つが大幅に変更された共有「ライブラリ」である場合、本番サイト全体をクラッシュさせることができます。


17
@JohnHamiltonコンパイルの自動化が難しいタスクである場合、それ自体は長期的に解決すべきものです。開発、テスト、運用前環境を完全に自動化された展開で完了する必要はありませんが、標準の展開パッケージの作成は標準的なプラクティスである必要があります。
ニール

20
えー、会社の規模は問題ではありません(ある程度)。コストは、展開が自動化される範囲に関連し、実稼働環境の複雑さに関連します。しかし、自動化の勾配と「コスト」(時間/お金)の勾配があり、ビルド出力を本番環境にコピーするスクリプトのような単純なものから始まり(すぐに目に見えるコスト削減を伴う小さな投資)、そこから増加します。会社の規模よりも経営上の買い取りについて。
BurnsBA

39
@JohnHamilton:うまく管理されていない小さな会社は、それを考えるようになるかもしれません。ファイルのコピーを自動化することは必ずしも難しい作業ではありません。雇用された人に定期的にこれを行わせるコストは、それを行うための最も些細なスクリプトを書くコストよりもはるかに大きくなります。
GManNickG

8
@JohnHamilton:自動化のコストは、手動展開中にミスが発生するリスクと比較検討する必要があります。
ロバートハーベイ

7
ジェンキンスは必ずしも必要ではありません。多数のscpコマンド(または手動でアップロードするときに使用するもの)を含むチェックインスクリプトだけで改善されます。
user253751

14

手動の手順は多くの労力を要し、危険です。必要なファイルを忘れてしまう可能性があります。チームの全員がどのファイルをコピーする必要があるかを知っているとは限りません。これらの問題はすべて、デプロイメントを大きく、困難で、まれなものにします-完全に不必要です。オートメーションはこれらに対処します。

展開が簡単になるため、最も単純な自動化ステップでも大きなメリットがあります。(S)FTP、Rsync、または別のテクノロジーを介してファイルまたはアーティファクトをコピーするスクリプトは、素晴らしい最初のステップです。後でそのスクリプトを展開して、サービスの再起動など、サーバーで展開前および展開後の手順を自動的に実行できます。


サーバーの総数が2以下の場合、手動の方が自動よりもリスクが低くなります。自動では、広範なバグチェックが必要です。私は些細なままでいた些細な自動ソリューションを見たことがない。
ジョシュア

3
@Joshuaここでは、サーバーの数が要因になるかどうかわかりません。自動化は、同じサーバーに複数回展開する場合にも価値があります。問題は、誰がより信頼できるかです。コンピューターは、一度機能したスクリプトを忠実に実行しますか、それとも、必要なすべてのステップを毎回記憶する能力ですか?間違いやすく忘れっぽい人間として、私は手作業を行わないことを強く好みます。コマンドを実行する前に確認できるように、1回限りのタスクのスクリプトを作成することもあります。それは、うまくいくまで手動でランダムに行うよりもはるかにリスクが少ないです!
アモン

私は両方の方法で幅広い経験を持っています。手動で展開するために作成するのはxcopyインストールなので、いくつかを忘れる必要はありません。
ジョシュア

9

ベストプラクティスは、何らかの自動プロセスを実装することです。

あなたが考慮しなければならない「ファイルごと」アプローチの特別な理由がないことを確認するように注意してください。


1
この質問をするのは、それが世界のベストプラクティスではないことを確認したいからです。まだアプリ/プロジェクトを手動で展開している企業/開発者はまだいるのでしょうか、さらに悪いことに、開発の各反復ごとにファイルごとに展開しているのです。
ジェイクミュラー

4
質問するのに最適な質問は、「なぜこのようにするのですか?」です。私はその理由を考えるカントが、私はそれがあったように、いくつかの企業が引き金に手動手を維持したいということを知っています
ユアン・

8
@JakeMullerこの答えの行間で読むべきことは、状況について推論することで決定を下すべきであり、それについて知らない誰かが常に正しい答えを宣言したことを奴隷的に守ることではないということです。
Blrfl

ファイルごとのアプローチの理由は、ファイル間の依存関係である可能性があるため、ファイルの更新は、それらのファイルに依存する他のファイルへの変更の前に展開されます。間違った順序でファイルを更新すると、システムが一時的に停止する可能性があります。
bdsl

6

継続的配信(実際には展開)と各ファイルを手動で移動することで、2つの極端な状況を確認できます。完全に自動化されたパイプラインを(まだ)作成できない、または作成したくないことは完全に理解できます。ただし、プロセスの一部の自動化を検討する必要があります。

各ファイルを手動で移動するのは非常に危険です。たとえば、コードリポジトリにタグを付け、コンピューターでそのタグをチェックアウトし、アーティファクトを構築してサーバーにアップロードすることにより、そのリスクを軽減できます。これらの各ステップは、マウスを数回クリックするだけで実行されるように自動化できます。これにより、ファイルを忘れたり、誤って余分なファイルをプッシュするリスクが大幅に減少します。

一度に1ステップずつ、できることを自動化します。完全に自動化されたCDパイプラインを購入する余裕がないという事実は、一部の部品の自動化を妨げるものではありません。


1

ベストプラクティスは、特定の企業の特定の展開に対してコスト/利益分析を行うことです。

一般的な答えは、「手動で物事を行うな、自動化する」です。一般的に、これは一般的な種類の企業にとって正しい答えです。受け取った回答の均一性は、コミュニティがこれをベストプラクティスであるとどれだけ強く感じているかを示すものでなければなりません。あなたの会社が、自動化が適切なツールではないと感じている場合、彼らは何がそれらをユニークにするかを理解する必要があります。その一意性は、意思決定プロセスに考慮される必要があります。サンプルセットが1の場合、「ベストプラクティス」はありません。

「ファイル数」や「更新頻度」、「破壊の結果は何か」、「悪い変更をどれだけ迅速にロールバックできるか」などの質問は、答える重要な質問です。自動化すると、これらの質問の多くは重要ではなくなりますが、手動更新プロセスのコストと利点を適切に割り当てるために不可欠です。


1

手動のファイルごとのコピーと連続配信の間には、多くのグレーの濃淡があります。

展開プロセスの複雑さを軽減することから始めます。たとえば、zipファイル、rpmスタイルのパッケージ化、コード管理ツールとしてのインフラストラクチャ(パペットやシェフなど)、またはファイルをftpサーバーのステージング領域。

手動の手順が多い展開プロセスでは、エラーが発生する可能性が高くなります(したがって、失敗します)。

完全な継続的デリバリー(コストがかかり、時間をかけて努力/投資/イノベーションが必要)を実装する必要はありません。


0

使用しているソフトウェアテクノロジー(またはスタック)(解釈された言語、コンパイルされた言語、デスクトップアプリ、モバイルなど)、ソフトに依存します。開発者 部門ポリシー、自動化するツールがある場合、アプリの重要度、および考慮すべき重要なことの1つは、ソフトウェアアーキテクチャ(アプリの設計方法)です。あなたがここで異なる答えを持っているのはこのためです。経験則として、最良のアプローチは、ミスを避けるために、展開タスクにおける人間の介入を可能な限り減らすことです。展開する前にQAサーバーのすべてをテストし(予算が問題になる場合は仮想サーバーを使用することを検討してください)、災害の場合に以前のバージョンに復元するための逆の手順を用意してください(常にバックアップが必要です)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.