Code Promotion: Compliance

Question

So here is our problem:

We have a small development team with our own ways of doing things. I am trying to formalize a process in which we must promote our code in the following order:

Local Sandbox> Dev> UAT> Staging> Live

Developers develop / test as they go on their own sandbox, Dev is our own box, which we will use for continuous integration, UAT is another site in IIS in dev that uses our dev database. Then we advance the stage, which is the site in IIS on the Live box and using live data (just like in live mode, therefore, staging). Then, finally, we move forward to live.

Here are some of my questions:

1.) Does this seem like best practice? If not, what needs to be done differently?

2.) How to ensure that developers comply with the rules? Often, developers skip steps to save time ... this is not to be tolerated and it would be great if it could be physically forced.

3.) How to include these rules in a business group? The business group just wants to get FAST features. Do we support only certain days?

Answer 1

sounds like a good setting for me ... we have no areas where I work. We have DEV> QA> Production.

1) I'm not quite sure what “best practice” is, but your installation seems to me very good practice. My only concern will be in the Sandbox environment. Are there any assurances that the developer code is backed up daily? in case their car works hard? I would really like to lose some good developer code.

2) There is a “release coordinator” that provides access to Sourcesafe and TFS, and also controls access to the QA environment, so there are only certain points when they are available.

3) The same applies to business testers, except that their credentials come through project managers. PM has a document that is filled out for each project and test teams are indicated.

We only advance on certain days (every Thursday). However, we understand that emergencies can occur, and we produced products on weekends when it is required, but these emergencies are documented after the fact and analyzed to understand what went wrong and where we can make improvements.

I would say that while your environment is monitored and documented, you should be fine. It would be nice to make sure that everything in the backup storage is in the sandbox area and that a small group of people control access to other environments. I would also recommend keeping good documentation of the arrivals and events of “secured” environments, just in case something goes wrong, you can go back through the magazines and see what could happen or who could do it, it’s not necessary to indicate fingers but go back and say: "What exactly did you upload / change?" therefore we can see what might cause the problem.

Good luck to you,

Answer 2

Scott already answered pretty well, so I will not repeat his logic. He seems to have missed:

How to enforce these rules in a business group?

The problem is that you cannot provide anything in a business group. Only their managers can.

What you (as IT) can do is to meet with business group managers and post a cost / benefit analysis.

• Worst case error
• The likelihood of this error without proper process
• The cost of the company is such a mistake.

Ideally, a mistake would be something that actually happened in the past, not theoretical :)

Then compare this to a relatively minor one (just make some estimates, hopefully by inputting business users) to have the proper process and the associated slowdowns.

Basically, you need their buy-ins to convince them of their interest not to cut corners.

Answer 3

We have a similar installation in my store. We provide this through various physical machines and who have access via passwords, etc. I develop locally on my own VPC and then test the code. This is the end, as far as I know. Another person has access to the dev block, where he starts assemblies as necessary, he does not have access to the "live" box, the other person does. This person has access to both the "dev" and the "live" boxes - this way he can perform emercency deployment, etc., if necessary. After the assembly was sent to dev and was tested, then and only then a live assembly will be performed.