1

企業内で DEV から TEST、PROD へのコード昇格を他の人がどのように管理しているかに興味があります。

「お役所仕事」、つまり参入/退出基準を管理するために、どのようなツールまたはプロセスを使用していますか?

私の現在の組織は、ドキュメントを送信し、承認とレビューを収集するために、いくつかのカスタム オンライン フォーム タイプの機能と紙ベースの依存関係の間で行き詰っています。

これらはすべて、プロジェクト マネージャーの手に委ねられ、提出されたもの、審査に合格したもの、承認されたものを追跡し、アプリケーションを次の環境に昇格させる前に「見逃す」必要のある障害がある場合は管理者に通知します。

ブラウザ ベースのアプリケーションが理想的です。あなたのgooglefuが私のものより優れていることを見せてください。

4

2 に答える 2

3

グーグルで良いものを見つけるのは難しいです。問題管理用のツールは数多くありますので、私たちが使用しているものと使用したいものについて説明します。

現在、セレナ製品を使用しています。彼らは過去に私たちのためにうまくいきました. チーム トラックは私たちの問題管理であり、私たちが取り組んでいるすべての問題のライフ サイクルを処理します。Version Manager はソース コントロールであり、DEV TEST And PROD などのプロモーション グループを実装する機能を備えています。DEV、TSTAGE、TEST、PSTAGE、PROD を使用して、一方から他方への移動を表しますが、ほとんど同じです。2 つの製品は問題に関連するソースがリンクされるようにうまく統合されていますが、この環境ではビルド プロセスの設定がありません。高価ですが、うまく機能します。

問題管理に Jira、ソース管理に Subversion、2 つをリンクする Fisheye、ビルド管理に Cruise Control を使用する、より一般的なシステムへの移行を検討しています。これはより安価で、エンタープライズ ライセンスで合計数千ドルで、すべて同じ機能を提供しますが、非常に優れたコード バージョン マンガガーである SVN のボーナスが追加されています。

それが役立つことを願っています。

于 2008-10-09T22:50:25.920 に答える
0

There are a few different scenarios that I've experienced over the years:

Dev -> Test : There is usually a code freeze date that stops work on new features and gets a test environment the code that has been tagged/labelled/archived that gets built. This then gets copied onto the machines and the tests go fine. This is also usually the least detailed of any push.

Test->Prod : This requires the minor change that production has to go down which can mean that a "gone fishing" page goes up or IIS doesn'thave any sites running and the code is copied over again. There are special cases to this where a load balancer can act as a switch so that the promotion happens and none of the customers experience any down time as the ones on the older server will move once their session ends.

To elaborate on that switch idea, the set up is to have 2 potentially live servers with just one server taking requests that the load balancer just sends all the traffic to one machine that can be switched when the other server has the updated code to go live.

There can also be a staging environment which is between test and production where the process is similar in terms of there is a set date when the promotion happens.

Where I used to work there would be merge days where a developer spent most of a day in Perforce merging code so that it could be promoted from one environment to another.

Now there are a couple of cases where this isn't used:

"Hotfixes" or "Hot patches" would occur where I used to work and in this case the specific files were copied up into the staging and production environments on its own since the code change had to get into Production ASAP since something broke in production or some new thing that had to get done that takes 2 minutes gets done. In this case, the code change getting pushed in had to be reviewed and approved before going out.

Those are the different approaches I've seen used where generally there are schedules and timelines potentially have to be changed or additional resources brought in to make a hard date like if a conference is on a particular weekend that such and such is ready for that.

Of course in a few places there has been the, "Oh, was that broken? Let me see..." and a few minutes later, "No, see it isn't broken for me," where someone changed things without asking permission or anything where a company still has what they call "cowboy programming."

Another point is the scale of the release: 1) Tiny - This is the case where one web page goes up so that user X can do Y.

2) Small - A handful or so of files that isn't really complicated but isn't exactly trivial.

3) Medium - Where going from one environment to another requires changing a bunch of files and usually has scripts to move.

4) Big - Where there are scheduled promotions and various developers are asked for who is taking which shifts when the live push is done. I had this in a case where there was a data migration to do in addition to a release of some new e-commerce sites.

5) Mammoth - Where everything is brand new including how this would be used. I don't think I've ever seen one of this size but I'd imagine Microsoft or Google would have releases of this size.

Somewhere in that spectrum most releases fall and so how much planning and preparation can vary quite a bit and let's not forget that regulatory compliance can be its own pain in getting some things done.

于 2008-10-09T23:11:33.570 に答える