Return to Answer

The other answers cover a lot, but I will add something slightly different.

Why do your processes allow him access to any production server in an open manner?

You should be setting up your deployment system so it is automated, reproducible and closed - no one should be able to circumvent the deployment system.

1. Remove all developers access to the production servers. Allow them remote access to the system logs and the debuggers, but thats it.

2. Run all your code build and packaging via a Continuous Integration system  , such as TeamCity.

3. TeamCity builds your specific branches and tags in git - have it run the unit tests and integration tests.

4. Deploy all your code via an automated deployment system such as Octopus Deploy - this will take the packaged output of your CI system and deploy it in an automated and reproducible fashion into any environment you have set up. It can deploy specific branches to your dev environment, promote those packages to UAT or Production, and it will never allow your developers to muck around in production. It also gives you a full audit log of whats been deployed where.

Use the processes to enforce the restrictions on your developers - until you do, you will always get someone circumventing your manual processes because they are "better than you".

If your developers dont have admin rights to the production servers, they cant circumvent your processes.

Your deployment processes are part of your system - in the event of a server rebuild, you should be able to deploy all your code in an identical fashion as before. You will find this incredibly difficult to do when the deployment process is manual, as so much is undocumented, while if the deployment process is automated then at least the automation configuration acts as minimal documentation - you just click one button and have all relevant packages deployed to the new server. No fuss, no problems, just done.

Edit: Also, see my answer to How to avoid bad practices of work by employees, as it is also relevant to your situation. You need to act as the gatekeeper, and to do that you need to actually pit some gates into practice.

Second edit: a few people in the comments have expressed the concern that this isnt an immediate fix - unfortunately, unless the developer in question has an overnight epiphany then nothing short of that developer leaving will be an immediate fix.

TeamCity and Octopus Deploy (you dont have to use those, there are others out there) are quite easy to get up and running - they should take a day or so to get installed and configured, plus an hour or so of per project configuration.

However, even just starting the process of automating the deployment process should trigger something in the problem developer - it should immediately show them which way the wind is blowing, and that may be enough to have them make a decision one way or the other. Should they stay and fall in line with the team lead, or should they continue to be insular and risk having to leave...

One other thing to consider is that what this developer is doing is showing other team members that they can get away with bad practice - I'm betting there are other team members who quietly do fixes in production, cover up mistakes etc. These are the sorts of things that will quickly lead to you not being able to rebuild an identical production system if that need should arise. And believe me, it will arise.

The other answers cover a lot, but I will add something slightly different.

Why do your processes allow him access to any production server in an open manner?

You should be setting up your deployment system so it is automated, reproducible and closed - no one should be able to circumvent the deployment system.

1. Remove all developers access to the production servers. Allow them remote access to the system logs and the debuggers, but that's it.

2. Run all your code build and packaging via a Continuous Integration system, such as TeamCity.

3. TeamCity builds your specific branches and tags in git - have it run the unit tests and integration tests.

4. Deploy all your code via an automated deployment system such as Octopus Deploy - this will take the packaged output of your CI system and deploy it in an automated and reproducible fashion into any environment you have set up. It can deploy specific branches to your dev environment, promote those packages to UAT or Production, and it will never allow your developers to muck around in production. It also gives you a full audit log of whats been deployed where.

Use the processes to enforce the restrictions on your developers - until you do, you will always get someone circumventing your manual processes because they are "better than you".

If your developers don't have admin rights to the production servers, they can't circumvent your processes.

Your deployment processes are part of your system - in the event of a server rebuild, you should be able to deploy all your code in an identical fashion as before. You will find this incredibly difficult to do when the deployment process is manual, as so much is undocumented, while if the deployment process is automated then at least the automation configuration acts as minimal documentation - you just click one button and have all relevant packages deployed to the new server. No fuss, no problems, just done.

Edit: Also, see my answer to How to avoid bad practices of work by employees, as it is also relevant to your situation. You need to act as the gatekeeper, and to do that you need to actually pit some gates into practice.

Second edit: a few people in the comments have expressed the concern that this isn't an immediate fix - unfortunately, unless the developer in question has an overnight epiphany then nothing short of that developer leaving will be an immediate fix.

TeamCity and Octopus Deploy (you don't have to use those, there are others out there) are quite easy to get up and running - they should take a day or so to get installed and configured, plus an hour or so of per project configuration.

However, even just starting the process of automating the deployment process should trigger something in the problem developer - it should immediately show them which way the wind is blowing, and that may be enough to have them make a decision one way or the other. Should they stay and fall in line with the team lead, or should they continue to be insular and risk having to leave...

One other thing to consider is that what this developer is doing is showing other team members that they can get away with bad practice - I'm betting there are other team members who quietly do fixes in production, cover up mistakes etc. These are the sorts of things that will quickly lead to you not being able to rebuild an identical production system if that need should arise. And believe me, it will arise.

The other answers cover a lot, but I will add something slightly different.

Why do your processes allow him access to any production server in an open manner?

You should be setting up your deployment system so it is automated, reproducible and closed - no one should be able to circumvent the deployment system.

1. Remove all developers access to the production servers. Allow them remote access to the system logs and the debuggers, but thats it.

2. Run all your code build and packaging via a Continuous Integration system , such as TeamCity.

3. TeamCity builds your specific branches and tags in git - have it run the unit tests and integration tests.

4. Deploy all your code via an automated deployment system such as Octopus Deploy - this will take the packaged output of your CI system and deploy it in an automated and reproducible fashion into any environment you have set up. It can deploy specific branches to your dev environment, promote those packages to UAT or Production, and it will never allow your developers to muck around in production. It also gives you a full audit log of whats been deployed where.

Use the processes to enforce the restrictions on your developers - until you do, you will always get someone circumventing your manual processes because they are "better than you".

If your developers dont have admin rights to the production servers, they cant circumvent your processes.

Your deployment processes are part of your system - in the event of a server rebuild, you should be able to deploy all your code in an identical fashion as before. You will find this incredibly difficult to do when the deployment process is manual, as so much is undocumented, while if the deployment process is automated then at least the automation configuration acts as minimal documentation - you just click one button and have all relevant packages deployed to the new server. No fuss, no problems, just done.

Edit: Also, see my answer to How to avoid bad practices of work by employees, as it is also relevant to your situation. You need to act as the gatekeeper, and to do that you need to actually pit some gates into practice.

Second edit: a few people in the comments have expressed the concern that this isnt an immediate fix - unfortunately, unless the developer in question has an overnight epiphany then nothing short of that developer leaving will be an immediate fix.

TeamCity and Octopus Deploy (you dont have to use those, there are others out there) are quite easy to get up and running - they should take a day or so to get installed and configured, plus an hour or so of per project configuration.

However, even just starting the process of automating the deployment process should trigger something in the problem developer - it should immediately show them which way the wind is blowing, and that may be enough to have them make a decision one way or the other. Should they stay and fall in line with the team lead, or should they continue to be insular and risk having to leave...

One other thing to consider is that what this developer is doing is showing other team members that they can get away with bad practice - I'm betting there are other team members who quietly do fixes in production, cover up mistakes etc. These are the sorts of things that will quickly lead to you not being able to rebuild an identical production system if that need should arise. And believe me, it will arise.

The other answers cover a lot, but I will add something slightly different.

Why do your processes allow him access to any production server in an open manner?

You should be setting up your deployment system so it is automated, reproducible and closed - no one should be able to circumvent the deployment system.

1. Remove all developers access to the production servers. Allow them remote access to the system logs and the debuggers, but thats it.

2. Run all your code build and packaging via a Continuous Integration system , such as TeamCity.

3. TeamCity builds your specific branches and tags in git - have it run the unit tests and integration tests.

4. Deploy all your code via an automated deployment system such as Octopus Deploy - this will take the packaged output of your CI system and deploy it in an automated and reproducible fashion into any environment you have set up. It can deploy specific branches to your dev environment, promote those packages to UAT or Production, and it will never allow your developers to muck around in production. It also gives you a full audit log of whats been deployed where.

Use the processes to enforce the restrictions on your developers - until you do, you will always get someone circumventing your manual processes because they are "better than you".

If your developers dont have admin rights to the production servers, they cant circumvent your processes.

Your deployment processes are part of your system - in the event of a server rebuild, you should be able to deploy all your code in an identical fashion as before. You will find this incredibly difficult to do when the deployment process is manual, as so much is undocumented, while if the deployment process is automated then at least the automation configuration acts as minimal documentation - you just click one button and have all relevant packages deployed to the new server. No fuss, no problems, just done.

Edit: Also, see my answer to How to avoid bad practices of work by employees, as it is also relevant to your situation. You need to act as the gatekeeper, and to do that you need to actually pit some gates into practice.

Second edit: a few people in the comments have expressed the concern that this isnt an immediate fix - unfortunately, unless the developer in question has an overnight epiphany then nothing short of that developer leaving will be an immediate fix.

TeamCity and Octopus Deploy (you dont have to use those, there are others out there) are quite easy to get up and running - they should take a day or so to get installed and configured, plus an hour or so of per project configuration.

However, even just starting the process of automating the deployment process should trigger something in the problem developer - it should immediately show them which way the wind is blowing, and that may be enough to have them make a decision one way or the other. Should they stay and fall in line with the team lead, or should they continue to be insular and risk having to leave...

One other thing to consider is that what this developer is doing is showing other team members that they can get away with bad practice - I'm betting there are other team members who quietly do fixes in production, cover up mistakes etc. These are the sorts of things that will quickly lead to you not being able to rebuild an identical production system if that need should arise. And believe me, it will arise.

The other answers cover a lot, but I will add something slightly different.

Why do your processes allow him access to any production server in an open manner?

You should be setting up your deployment system so it is automated, reproducible and closed - no one should be able to circumvent the deployment system.

1. Remove all developers access to the production servers. Allow them remote access to the system logs and the debuggers, but thats it.

2. Run all your code build and packaging via a Continuous Integration system , such as TeamCity.

3. TeamCity builds your specific branches and tags in git - have it run the unit tests and integration tests.

4. Deploy all your code via an automated deployment system such as Octopus Deploy - this will take the packaged output of your CI system and deploy it in an automated and reproducible fashion into any environment you have set up. It can deploy specific branches to your dev environment, promote those packages to UAT or Production, and it will never allow your developers to muck around in production. It also gives you a full audit log of whats been deployed where.

Use the processes to enforce the restrictions on your developers - until you do, you will always get someone circumventing your manual processes because they are "better than you".

If your developers dont have admin rights to the production servers, they cant circumvent your processes.

Your deployment processes are part of your system - in the event of a server rebuild, you should be able to deploy all your code in an identical fashion as before. You will find this incredibly difficult to do when the deployment process is manual, as so much is undocumented, while if the deployment process is automated then at least the automation configuration acts as minimal documentation - you just click one button and have all relevant packages deployed to the new server. No fuss, no problems, just done.

Edit: Also, see my answer to How to avoid bad practices of work by employees, as it is also relevant to your situation. You need to act as the gatekeeper, and to do that you need to actually pit some gates into practice.

The other answers cover a lot, but I will add something slightly different.

Why do your processes allow him access to any production server in an open manner?

You should be setting up your deployment system so it is automated, reproducible and closed - no one should be able to circumvent the deployment system.

1. Remove all developers access to the production servers. Allow them remote access to the system logs and the debuggers, but thats it.

2. Run all your code build and packaging via a Continuous Integration system , such as TeamCity.

3. TeamCity builds your specific branches and tags in git - have it run the unit tests and integration tests.

4. Deploy all your code via an automated deployment system such as Octopus Deploy - this will take the packaged output of your CI system and deploy it in an automated and reproducible fashion into any environment you have set up. It can deploy specific branches to your dev environment, promote those packages to UAT or Production, and it will never allow your developers to muck around in production. It also gives you a full audit log of whats been deployed where.

Use the processes to enforce the restrictions on your developers - until you do, you will always get someone circumventing your manual processes because they are "better than you".

If your developers dont have admin rights to the production servers, they cant circumvent your processes.

Your deployment processes are part of your system - in the event of a server rebuild, you should be able to deploy all your code in an identical fashion as before. You will find this incredibly difficult to do when the deployment process is manual, as so much is undocumented, while if the deployment process is automated then at least the automation configuration acts as minimal documentation - you just click one button and have all relevant packages deployed to the new server. No fuss, no problems, just done.

Edit: Also, see my answer to How to avoid bad practices of work by employees, as it is also relevant to your situation. You need to act as the gatekeeper, and to do that you need to actually pit some gates into practice.

Second edit: a few people in the comments have expressed the concern that this isnt an immediate fix - unfortunately, unless the developer in question has an overnight epiphany then nothing short of that developer leaving will be an immediate fix.

TeamCity and Octopus Deploy (you dont have to use those, there are others out there) are quite easy to get up and running - they should take a day or so to get installed and configured, plus an hour or so of per project configuration.

However, even just starting the process of automating the deployment process should trigger something in the problem developer - it should immediately show them which way the wind is blowing, and that may be enough to have them make a decision one way or the other. Should they stay and fall in line with the team lead, or should they continue to be insular and risk having to leave...

One other thing to consider is that what this developer is doing is showing other team members that they can get away with bad practice - I'm betting there are other team members who quietly do fixes in production, cover up mistakes etc. These are the sorts of things that will quickly lead to you not being able to rebuild an identical production system if that need should arise. And believe me, it will arise.