2 It's means "it is"; its is the pronoun.
source | link

So thisSo this answer is from the point of a developer. Keep that in mind.

First, not having "local admin" rights on my own machine is a sign that I should look for a job elsewhere. It's nearly impossible to write code, fiddle with stuff, and maintain a toolchain if you have to ask permission every-time you need to update (or test out) a new dependency or tool. So, here are the permission levels I require. Keep in mind I am usually pretty high up on the ladder so to speak.

  • Total and complete Admin over my local machine
  • Total and complete Admin over all development and testing hardware
  • Some level of admin access to the production servers (this gets tricky I don't need or want everything, but I need enough to diagnose and fix problems that occur on production, and enough to actually deploy code (assuming that I'm the one that has to oversee code deployment). Usually this level of access evolves over time, but starts with log files.

Less then that, and you can go find a new developer.

That said, there is a lot of risk involved with that level of access. So what I normally recommend is a separate network. Put all the dev "stuff" in it'sits own network. It'sIts own AD, it'sits own file hosting, it'sits own everything, and never let it talk to the production network. (But do let it get out to the internet)

Yes this means duplicate hardware (or VPSs) but you need that anyway for testing. Yes it means a little bit more overhead when upgrading or administrating, but again, it's needed for testing. You also need a place to see "What happens to X software if I upgrade the AD server?" Look at that you have an entire network of test machines ready for that kind of test.

What I have successfully implemented (with the help of a good IT team) is a separate VLAN for all dev "stuff" and a single VPS host that dev has full access to, to do with what ever it wants. On that host is an AD server that is setup by IT to look like a smaller version of the companies AD server. Then a set of documents and guidelines for what a, for example, webserver should run. What a DNS server should run, what a xyz server should run. Then, part of "development" is to install and configure those VPSs for our use. Everything on that VLAN is totally isolated from production, and considered external to the company. Finally a set of "punch throughs" are created for assets that we did need access to (like email). Normally this was handled as if we were external, and the list of these tools were very small.

So this answer is from the point of a developer. Keep that in mind.

First, not having "local admin" rights on my own machine is a sign that I should look for a job elsewhere. It's nearly impossible to write code, fiddle with stuff, and maintain a toolchain if you have to ask permission every-time you need to update (or test out) a new dependency or tool. So, here are the permission levels I require. Keep in mind I am usually pretty high up on the ladder so to speak.

  • Total and complete Admin over my local machine
  • Total and complete Admin over all development and testing hardware
  • Some level of admin access to the production servers (this gets tricky I don't need or want everything, but I need enough to diagnose and fix problems that occur on production, and enough to actually deploy code (assuming that I'm the one that has to oversee code deployment). Usually this level of access evolves over time, but starts with log files.

Less then that, and you can go find a new developer.

That said, there is a lot of risk involved with that level of access. So what I normally recommend is a separate network. Put all the dev "stuff" in it's own network. It's own AD, it's own file hosting, it's own everything, and never let it talk to the production network. (But do let it get out to the internet)

Yes this means duplicate hardware (or VPSs) but you need that anyway for testing. Yes it means a little bit more overhead when upgrading or administrating, but again, it's needed for testing. You also need a place to see "What happens to X software if I upgrade the AD server?" Look at that you have an entire network of test machines ready for that kind of test.

What I have successfully implemented (with the help of a good IT team) is a separate VLAN for all dev "stuff" and a single VPS host that dev has full access to, to do with what ever it wants. On that host is an AD server that is setup by IT to look like a smaller version of the companies AD server. Then a set of documents and guidelines for what a, for example, webserver should run. What a DNS server should run, what a xyz server should run. Then, part of "development" is to install and configure those VPSs for our use. Everything on that VLAN is totally isolated from production, and considered external to the company. Finally a set of "punch throughs" are created for assets that we did need access to (like email). Normally this was handled as if we were external, and the list of these tools were very small.

So this answer is from the point of a developer. Keep that in mind.

First, not having "local admin" rights on my own machine is a sign that I should look for a job elsewhere. It's nearly impossible to write code, fiddle with stuff, and maintain a toolchain if you have to ask permission every-time you need to update (or test out) a new dependency or tool. So, here are the permission levels I require. Keep in mind I am usually pretty high up on the ladder so to speak.

  • Total and complete Admin over my local machine
  • Total and complete Admin over all development and testing hardware
  • Some level of admin access to the production servers (this gets tricky I don't need or want everything, but I need enough to diagnose and fix problems that occur on production, and enough to actually deploy code (assuming that I'm the one that has to oversee code deployment). Usually this level of access evolves over time, but starts with log files.

Less then that, and you can go find a new developer.

That said, there is a lot of risk involved with that level of access. So what I normally recommend is a separate network. Put all the dev "stuff" in its own network. Its own AD, its own file hosting, its own everything, and never let it talk to the production network. (But do let it get out to the internet)

Yes this means duplicate hardware (or VPSs) but you need that anyway for testing. Yes it means a little bit more overhead when upgrading or administrating, but again, it's needed for testing. You also need a place to see "What happens to X software if I upgrade the AD server?" Look at that you have an entire network of test machines ready for that kind of test.

What I have successfully implemented (with the help of a good IT team) is a separate VLAN for all dev "stuff" and a single VPS host that dev has full access to, to do with what ever it wants. On that host is an AD server that is setup by IT to look like a smaller version of the companies AD server. Then a set of documents and guidelines for what a, for example, webserver should run. What a DNS server should run, what a xyz server should run. Then, part of "development" is to install and configure those VPSs for our use. Everything on that VLAN is totally isolated from production, and considered external to the company. Finally a set of "punch throughs" are created for assets that we did need access to (like email). Normally this was handled as if we were external, and the list of these tools were very small.

1
source | link

So this answer is from the point of a developer. Keep that in mind.

First, not having "local admin" rights on my own machine is a sign that I should look for a job elsewhere. It's nearly impossible to write code, fiddle with stuff, and maintain a toolchain if you have to ask permission every-time you need to update (or test out) a new dependency or tool. So, here are the permission levels I require. Keep in mind I am usually pretty high up on the ladder so to speak.

  • Total and complete Admin over my local machine
  • Total and complete Admin over all development and testing hardware
  • Some level of admin access to the production servers (this gets tricky I don't need or want everything, but I need enough to diagnose and fix problems that occur on production, and enough to actually deploy code (assuming that I'm the one that has to oversee code deployment). Usually this level of access evolves over time, but starts with log files.

Less then that, and you can go find a new developer.

That said, there is a lot of risk involved with that level of access. So what I normally recommend is a separate network. Put all the dev "stuff" in it's own network. It's own AD, it's own file hosting, it's own everything, and never let it talk to the production network. (But do let it get out to the internet)

Yes this means duplicate hardware (or VPSs) but you need that anyway for testing. Yes it means a little bit more overhead when upgrading or administrating, but again, it's needed for testing. You also need a place to see "What happens to X software if I upgrade the AD server?" Look at that you have an entire network of test machines ready for that kind of test.

What I have successfully implemented (with the help of a good IT team) is a separate VLAN for all dev "stuff" and a single VPS host that dev has full access to, to do with what ever it wants. On that host is an AD server that is setup by IT to look like a smaller version of the companies AD server. Then a set of documents and guidelines for what a, for example, webserver should run. What a DNS server should run, what a xyz server should run. Then, part of "development" is to install and configure those VPSs for our use. Everything on that VLAN is totally isolated from production, and considered external to the company. Finally a set of "punch throughs" are created for assets that we did need access to (like email). Normally this was handled as if we were external, and the list of these tools were very small.