タグ付けされた質問 「production」

9
実動サーバーでの開発
今日、私は本番サーバーでアプリケーションを開発することで怒鳴られました。「実稼働サーバーでの開発は受け入れられません-これまでに!」 これが状況です。 開発インスタンスをセットアップしました。 http://example.com:3000 実稼働インスタンスは次のとおりです。 http://example.com すべての開発作業を完了し、http://example.com:3000クライアントが変更に満足したら、それらをに移動しますhttp://example.com。 私が使用しているアプリケーションは古いRuby on Railsアプリケーションです。最初は開発環境をローカルに設定しようとしましたが、実行することはできませんでした。しばらく試した後、私はあきらめ、本番サーバーで開発することにしました。 繰り返しますが、私はばかですか?おそらくそうですが、私はここ数年、Web開発を行ってきましたが、このような状況に遭遇したことはありません。誰が正しいのか?

15
極度の不安を感じることなく、本番の展開を自動化するにはどうすればよいですか?
当店では、ソース管理にSVNを、CIにCruiseControlを使用して、開発、テスト、および統合環境への自動ビルドと展開を処理しています。 これはすべてスムーズに機能しますが、ハードウェアとリソースの制約により、統合環境は運用環境のような2サーバーの負荷分散環境ではありません。それ以外はすべて同じですが、それが統合環境と実稼働環境の唯一の違いです(ただし、大きな環境です!) 理論的には、違いはアプリサーバーのわずかに異なる構成であり、デプロイスクリプトはビルドアーティファクトを1つだけではなく2つのサーバーにドロップするだけでよいのですが、なぜ本番デプロイを自動化するのにそんなに緊張するのでしょうか?! 私は一般的にコントロールマニアではありませんが、手作業でプロダクションにプロダクションを展開する必要性を常に感じています。私はこれが一般的に本当に悪いこと™であると同僚から聞いたが、彼らはそれに対して主張をすることに失敗した。 手動で行うと、正しいファイルを物理的にコピーしていること、アプリサーバーを物理的にシャットダウンし、正常に終了したことを確認できます。正常に起動し、展開が成功したことを確認してください。それは私に心の安らぎを与えます。 自動スクリプト化された運用展開のこのOR引数に対する引数は何ですか?


11
本番システムがダウンしたとき、どのようにクールに保ちますか?[閉まっている]
これは私たちのほとんどに起こりました... あなたはいつか仕事に来ます。すべてが正常なようです-太陽は輝いており、鳥はさえずりますが、あなたは仕事中にいくつかの奇妙なことに気づき、それがマトリックスのデジャヴ猫を思い出させます。 あなたがオフィスに入ると、たくさんの電話が鳴っています-しかし、それは彼らが新しい販売促進をしているということだけかもしれません。暗い雲があなたの上に浮かんでいることに気づいたら、あなたは落ち着きます。 少し時間がかかりますが、クラウドがあなたの上司であることを認識しています。通常、彼は毎朝「Soooo Peeeeter、これらのTCP / IPレポートはどうですか?」であなたをチェックします。しかし、今日、彼は一般的なマナーについてすべてを忘れて、あなたの個人的なスペースに無作法に侵入しました。「おはよう」はなく、ただいくつかのよだれ、うなり声と呪い。彼は、サイバーボールの虎、恐怖、パニックからすべて逃げようとしているネアンデルタール人のことを思い出させます。昨日から彼が作成した新しい言語を解読しようとすると、何か悪いことが夜通し起こったことを理解し始めます-本番システムがダウンしました。 現在、システムは通常、クライアントによって9時から5時までの通常の営業時間に使用されますが、何らかの理由でブザーでアラートを受信しませんでした(30歳未満の場合-ブザーは鳴るだけの携帯電話のようでした)誰があなたにビープ音を鳴らしたか教えてください)。次回充電することを忘れないでください。 そのため、現在は午前8時45分であり、システムは午前9時でなければなりません。10秒ごとに、上司はさらに別の呪いを解き放ち、別の顧客がシステムに入るのに問題があることを伝えます。また、数人のアカウントマネージャーが上司にカーソルを合わせて、クライアントが本当に本当に苦しんでいるのかを理解させようとしています。 誰もがシステムをできるだけ早く起動することをあなたに依存していると同時に、常にあなたの注意をそらすことによってあなたの進歩を妨げています。 このような状況でどのようにクールに保ちますか?

7
「生産準備完了」を定義する
私はこれについてしばらく興味がありました。「生産準備完了」またはその変種とは正確には何を意味しますか?ごく最近、私はsqliteに関する情報を探していましたが、このスレッドを見つけました。多くの人がsqliteの生産準備が整っていないことを示唆しています。 開発/テストと本番の違いを知っています。私の生産の定義は、顧客に提供されるか、プログラマー以外によって使用されるものです。 ただし、生産準備完了として定義されていない多くのアイテムがあるようです。しかし、実際には、それらは完全に適している場合があり、人々はそれらに対して、例えばsqlite、python、非MS製品などのように偏見を持っているだけです。 小規模オフィスとエンタープライズのどちらですか?シングルユーザーとマルチユーザーのどちらですか?クライアント対サーバー?どこで線を引きますか?
25 production 

6
本番環境で問題が発生した場合の問題を理解する
シナリオ: 本番にプッシュします プッシュは複数のことを壊しました その同じビルドはqaまたはdevを壊しませんでした 開発者は、製品にアクセスできません。 物事を機能させるには、上から多くのプレッシャーがあります。 詳細: ZendでAPI駆動型のPHP / MVCアプリケーション。 少数のサーバーに展開されました。 私の質問: 調査中に、何かが間違っているという予感があるとしましょう。しかし、私は確かに知りません。そしてもちろん、実稼働環境でテストすることはできません。その考えに基づいて修正案を提案している場合、問題が何であるかを理解する前に、それを試して適用し、機能するかどうかを確認するのが賢明でしょうか?
24 bug  production 

7
マネージャーは、開発と本番の複合環境を望んでいます
私は大規模な組織をサポートする小さなプログラミングチームで働いています。今年、マネージャーは、Oracle Apexテクノロジーを使用して会社データの大部分を処理することを決定しました。 Apexサーバーが1つしかないことを除いて、これは問題ありません。マネージャーは、すべてがその1つのインスタンスで発生することを決定しました。私たちのチームはアプリを開発していますが、マネージャーはそれらをデモし、社内のクライアントはそれらを使用します。 Apexへの投資が増え、アプリがより複雑になり、ユーザーの数が増えるにつれて、これが悪化すると予想されます。ベストプラクティスは、開発環境、テスト環境、および運用環境を別々にすることだと聞きましたが、なぜそうなのですか? 質問:開発環境、テスト環境、および運用環境を個別に用意する必要があるのはなぜですか?

1
実稼働環境で実行するJavaバージョンに関する考慮事項
技術の最先端を走る人もいます-何かが更新される日を更新します。本番環境では、これは適切ではありません。 現在の(Java 7)バージョンの生産準備が整っているかどうかを調査すると、もはや正しくない可能性のある大量の古い資料が作成されます(この記事の執筆時点では、Java 7は1年半にわたって公開されていますが、かなり長いようです) 。 実稼働環境を新しいバージョンのJavaにアップグレードすることが適切かどうかを判断するには、どのような考慮事項が必要ですか?

5
サーバーにMercurialをインストールし、hg pullを展開することをお勧めしますか?
私はこの1か月間に新しい仕事に着手しましたが、コードのソース管理がないようです。彼らは、ホスティングプロバイダーがバックアップを使用していることに依存しています。 少し話した後、私は間違いなくソース管理を使うべきだと上司に確信させ、それについて短いセミナーを行った後、チーム全体が参加しています。彼らはMercurialが大好きでした。 だから今、これが私たちの仕事のやり方です: º----------BitBucket º---------/ º--------/ 私自身とhg pullBitBucketの他の3人の開発者が変更を加えてから、BitBucketに変更hg pushを加えます。 展開のために、誰かが最新のファイルを実稼働サーバーにFTPで送信する必要があります。 サーバーにMercurialをインストールし、hg clone(その後hg pull)を使用して実稼働時にバージョンを最新に保つことを考えていました。 º---push->-----BitBucket----<-pull-----º (production server) º---push->----/ º---push->---/ これはいいアイデアですか?目に見えない潜在的な落とし穴はありますか?ここで誰かが似たようなことをしましたか?大規模なPHPフレームワークアプリケーションをどのようにデプロイしますか(Moodleを使用しています)?

3
ファーストクラスのライブラリを出荷しています。知っておく必要がある落とし穴はありますか?
私は自分のキャリアで「ファーストクラスライブラリ公開」の成果を解き明かそうとしているWeb開発者です。コミュニティの経験を活用して、可能な限りスムーズに進むための提案や推奨事項があるかどうかを確認したいと思います。知っておく必要のある詳細や落とし穴はありますか?ビルドプロセスについて何か特別なことはありますか? 私がいる場所は次のとおりです。 ライブラリはユニットテストされており、約97%のコードカバレッジがあります。 APIは十分に文書化されており、インテリセンスサポートのxmlドキュメントが作成されています パブリック/プライベートクラスアクセサーが正確かつ正しいことを確認しました。すべてのゲッター/セッターについても同じことが言えます エラー処理は私が望んでいるほど優雅ではありませんが、私は締め切りに間に合っており、今のところ「それがうまくいく」ことを受け入れています わかりやすいログはありません。Debug.Writelineが広く使用されていました...最近、これが私の経験不足を反映していることがわかりました:( あなたのアドバイスは大歓迎です! ライブラリはレポートの生成に使用されます。標準の帽子-読み取り専用データベースに接続し、計算を実行し、データをフォーマットし、応答ストリームに出力します。 私は、辞めたプログラマーの一人を補うためのフリンジリソースとしてタップされ、このタスクは「歯を切る」プロジェクトとして私に与えられました。クラスライブラリは、プロダクションコードを記述するときに使用する社内の他のプログラマ向けにリリースされる予定です。

6
マニュアル-最新情報
長い間市場に出回っている製品があるが、毎日活発に開発されている場合-マニュアルを更新する頻度はどれくらいですか?最新のバグ修正が常に出荷されたバージョンに含まれていると組織が判断したために、ユーザーが常に最新バージョンに更新されている場合。つまり、ある日バグを修正し、翌日それが本番環境に移行する可能性があります。

1
本番環境で使用しない場合に、ソフトウェア開発プロセスでdockerを使用する理由は何ですか?
Dockerには、ソフトウェア開発者の大規模なチーム(100)で私の職場の問題を解決する多くの可能性があり、私の職場の問題を解決するために使用されます。これも: 持つドッカーホストのクラスタを使用すると、上のジョブを実行できること 持つCIエージェントは、ドッキングウィンドウのイメージとして実行する必要があることとあなたが水平にスケールアップすることができますので、(とすべてのビルドが完全にクリーンで一貫していることを保証します) Android、JS、およびJavaビルド用のさまざまなエージェントの専門化 複数のコンテナーにまたがって並行してJUnitテストを実行する 以下のような開発ツール持つソナーとし、NPMJS で実行中の ドッキングウィンドウは、簡単にバージョン管理、チェックインとCIのパイプラインでそれらをアップグレードすることができますので(専用ホスト上に) フィードバックは私に戻ってきました: これがうまく機能していることはすばらしいことですが、Dockerエコシステムを理解することは、一部の人々にとって精神的な飛躍となります。dockerを本番環境で実行しないことはすでに確立されているため、このツールで人材をスキルアップすることに投資する理由はないと思います。 私の質問は、本番環境で使用しない場合に、ソフトウェア開発プロセスでdockerを使用する理由は何ですか?

1
製品品質のコードの特徴または機能は何ですか?
フリーランスプロジェクト(webアプリ)のコードを配信するのはこれが初めてです。また、コードの配布の経験があまりないため、プログラムを展開する準備ができているかどうかを判断するのに苦労しています。 私の理解では、本番レベルのコードには次の特性が必要です。 フォールトトレランス:キャッチされない例外を乗り切る能力 データの冗長性:ユーザーデータを失うことはありません スケーラビリティ:追加の負荷を処理するためにアプリを書き直す必要はありません テストカバレッジ:テストされた「まともな」量のコード これらの特性には、プログラム自体に固有のものもあれば、環境に関連するものもあります(複数のクラスターを使用しているかどうか)。ただし、環境に依存する特性でさえ、プログラムの設計方法に影響を与えます。 私の質問は次のとおりです。本番用コードを本番用ではないコードと大きく異なる他の特徴は何ですか? 質問の範囲を減らすために、ウェブアプリのみに焦点を当ててください。 編集:私は自分の状況に固有の特性を尋ねることで、範囲を絞り込もうとします。私はフリーランサーとして、VPSの購入から構成、コードの記述、デプロイまで、すべてを担当していました。プロジェクトとそのセットアップは十分に文書化されていますが、お客様はそれを維持することができません。アプリは複雑ではありませんが、多くの外部コンポーネントに依存しているため、これらのコンポーネントが変更/消失した場合、実際に壊れる傾向があります。目標は、顧客の介入なしで可能な限り長く続くことができるサービスをセットアップすることです。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.