Ask Slashdot: Should Developers Install Their Software Themselves? 288
Paul Carver writes "Should developers be responsible for installing the software they develop into production environments? What about System Test environments? I'm not a developer and I'm not all that familiar with Agile or DevOps, but it seems unhealthy to me to have software installs done by developers. I think that properly developed software should come complete with installation instructions that can be followed by someone other than the person who wrote the code. I'd like to hear opinions from developers. Do you prefer a workplace where you hand off packaged software to other teams to deploy or do you prefer to personally install your software into System Test and then personally install it into production once the System Testers have certified it? For context, I'm talking about enterprise grade, Internet facing web services sold to end users as well as large companies on either credit card billing or contractual basis with service level agreements and 24x7 Operations support. I'm not talking about little one (wo)man shops and free or Google style years long beta services."
Why not use tools that help do it? (Score:2, Informative)
Developers should use those and make sure users can install their software themselves.
Re:Why not use tools that help do it? (Score:5, Insightful)
This question was not directed as consumer application. It is direct at Enterprise applications. InstallShield just won't do it.
Developers should not install it. Nor should they help install it. If the Configuration Management team cannot do it themselves, then they need to send it back to the developer for better packaging or instructions.
This is to the developers benefit. When new environments are set up, they shouldn't have to contact the developer to deploy the application to those new environments.
And as always. Titles with questions are typically answered with a "no".
Re:Why not use tools that help do it? (Score:5, Informative)
::Applause::
Sorry, I just do not have the mod points at the moment.
The exactly, correct response.
As a developer, there is only so much I can do. And I really do not want calls in the middle of the night. If I can describe how to install my software to a production support team, then the software release isn't ready for production.
Re:Why not use tools that help do it? (Score:5, Funny)
If I can describe how to install my software to a production support team, then the software release isn't ready for production
- BOFH, is that you?
Re: (Score:3)
Well if you can explain it, it doesn't appear to be magic. And we all know that any sufficiently advanced technology is indistinguishable from magic. In addition, Marketing insist that our product must be more advanced than anyone else's, and Legal insist we can't release it before it's ready.
It's therefore trivially obvious that if it can be explained, it isn't advanced enough, therefore it isn't ready.
Shit, don't they teach bloody syllogisms where you're about to grow up?
Re:Why not use tools that help do it? (Score:5, Insightful)
Developers should not install it. Nor should they help install it. If the Configuration Management team cannot do it themselves, then they need to send it back to the developer for better packaging or instructions.
As a (web) developper, I strongly agree.
I'll just add that the Configuration Management team should have some knowledge about the software and the environment they manage.
I've often seen software come back because sombody did'nt have a clue what their job was. ("prerequisite: apache 2.x" should be enough for anyone: I don't have time to write a doc about how to install standard software, especially when I don't know the target server configuration)
Re: (Score:2, Insightful)
Re:Why not use tools that help do it? (Score:5, Insightful)
Of course the devs need to install it into their test environment. And QA needs to install it into their test environment, but Ops needs to install it on the production servers.
Re: (Score:3)
This is the best case scenario. Good luck finding even 1% of medium-large companies with even close to that good of a process and infrastructure.
Re: (Score:3, Interesting)
You Sir, are absolutely correct.
Database changes are a tricky matter though. Despite testing our upgrades on a copy, we feel its safest to
one or two developers on site during software upgrades, in the event that something goes pear shaped.
I also think if developers can be involved in running and monitoring the actual system, you will get
better stability, better diagnostics and simpler handling.
(Banking systems, inhouse "enterprisey" applications on unix servers)
Re: (Score:3)
It would be nice if the developers understood what went into managing their own code in production, but I don't think they should get too involved. When developers install things, there is a tendency for how they install it to be done in a one-off manner where they do all sorts of wonderful things like compile in modules that we can't use or they just thought looked cool. Then they wonder why things don't work the same way in production.
What I want from a developer is simply that they put the required log
Re:Why not use tools that help do it? (Score:5, Interesting)
If the Configuration Management team cannot do it themselves, then they need to send it back to the developer for better packaging or instructions.
Sorry, no. I couldn't disagree more. I've worked in places like that, were developers were unable to get close to the production servers, things wouldn't work in production (but worked fine in dev) and we were unable to do anything except send builds with more and more debug info, working late nights to get things done, with a client more and more pissed each day.
Then it turns out that contrary to what they said, dev and prod wasn't identical, in a number of important things such as library versions.
If the install team is unable to install it by fuck's sake *get a developer see the installation process by himself* so he can come back just once with all the data he needs.
Re: (Score:2, Informative)
It sounds like you're putting the blame/responsibility on the developer for determining what versions of what underlying software is installed. Isn't that what the dev & prod build guys are for?
The developer should be developing. Not testing. That's QA/production.
Re: (Score:2)
The developer should be developing. Not testing. That's QA/production.
Yes. And when the prod guys says "it doesn't work" where does the shit end up eventually?
Re:Why not use tools that help do it? (Score:5, Informative)
Re:Why not use tools that help do it? (Score:4, Insightful)
If Dev and Prod aren't identical, then their Configuration Management team has failed.
They usually aren't hardware wise for budget reasons, hardly ever are configuration and environment wise (considering other running programs as part the environment) and they definitely aren't identical user base wise.
While I understand devs shouldn't modify anything in prod, denying access to the system to see in real time what the fuck is going on when something doesn't work is just asking for the solution to take 10x, frustration, finger pointing and longer hours (usually the developers and often unpaid).
Seriously, nothing wrong in telling the developer "come down with me, I'll start the damn thing in front of you, you can check a bit of the system to you go back with a clue".
Re:Why not use tools that help do it? (Score:5, Insightful)
Re:Why not use tools that help do it? (Score:5, Informative)
One nice thing about virtualization. It's a lot easier to take a copy of a VM and spin it up somewhere so that the configuration *IS* the same and you can debug something without affecting the live systems. (Ok, technically there is a delta -- security permissions -- but that's the only thing that should be different, although it does sometimes make a difference.)
Re: (Score:2)
This.
The dream is that developers do not have access to production.
The reality is that PRODUCTION IS NOT DEV.
Companies will not pay the money needed to have dev be a copy of production.
They cut budgets and corners left and right and then schedules. Be creative! Work smarter not harder! Do more with less!
And then they put a 5 day procedure over getting access to production debug mode which requires approval by a half dozen people.
And then scream as the business loses customers who it would not have lost i
Re:Why not use tools that help do it? (Score:5, Insightful)
Sorry, no. I couldn't disagree more. I've worked in places like that, were developers were unable to get close to the production servers, things wouldn't work in production (but worked fine in dev) and we were unable to do anything except send builds with more and more debug info, working late nights to get things done, with a client more and more pissed each day.
Then it turns out that contrary to what they said, dev and prod wasn't identical, in a number of important things such as library versions.
If the install team is unable to install it by fuck's sake *get a developer see the installation process by himself* so he can come back just once with all the data he needs.
Then your process is screwed up. The solution isn't to open production to developers but to get your process fixed. Part of the process must be ensuring that the production environment is regularly and consistently copied over to development to ensure the problem you describe can't happen. That's the solution.
I have no problem with giving developers read-access so they can look at the production environment to "gather data" but developers must not be able to ever install or change anything in production. That's just good sense.
Re: (Score:3)
Then your process is screwed up.
You're missing the point. It's not "my" process. I'm usually a developer in the team that is working on the client's development systems following *their* process to the letter. Telling me that the process is broken doesn't help me at all. The process is what it is and since we have to live with it the best thing sysadmins and devs can do is cooperate a bit so that it's less painful for everyone.
Have you actually worked as a contractor for any major corporation? Many of the replies I see here seem to come
Re:Why not use tools that help do it? (Score:5, Insightful)
I have often worked as a contractor for major corporations, and I have worked with contractors as a system administrator. I was not accusing you of anything but I was criticizing the environment you were forced to operate in. If the development environment gets so out of sync with production that installs succeed in development and fail in production, the solution is not to allow developers to change production but to correct the environment.
If production doesn't match development (and/or test) then the whole process is broken! Development is invalid and testing is invalid. Both development and test must duplicate production or absolutely nothing done in development or tested in test can be trusted.
As a developer, years ago, I actually modified a running production environment and I was very lucky that nothing went wrong. I understand that it happens and, in broken environments, sometimes it must be done, but that doesn't make it safe or right.
Re: (Score:3, Insightful)
That an application "doesn't break" is only the very first test in a long list of criteria. Many applications that "don't break" will still corrupt data or cause other existing applications to fail.
Development done in a different environment that production is a
Re:Why not use tools that help do it? (Score:5, Insightful)
I'm a build and configuration manager (and a LONG long time software developer), and I completely agree.
If developers want to employ new (as in industry-wide, or new as in company-wide) technology, they are free to install, configure, test, and prove out the functionality and feasibility of the software on their own machine. But that should be the limit of their reach.
Any shared / integrated environment from QA on up to Pre-Prod and Prod, should be off-limits from a developers' sticky fingers. If there is an installation and / or configuration problem that arises with the application, AND a developer is needed for support, then they should absolutely be called in, but from a CONSULTATIVE role only. I.e., their fingers never touch a mouse or keyboard.
It's common (if not expected) for developers to build an intimate working relationship with the technology they're using. In the world of "familiarity breeds contempt", it means that a developer can overlook something that occurs "obvious" to them, but not to everyone else. How many times has a developer been "called in" to fix an installation problem, and the fix wasn't documented or proved out? (not to say that integrators are saints in this area, but they damn well SHOULD be). Or a developer has access to a test region, and just "hops onto the machine" to tweak a parameter that caused a test suite to fail?
QA (and QC Testers) need to count on the stability of a machine, it's known state. If a test is failing 100% of the time, it should keep failing. Or if it's passing 100% of the time, it should keep passing. Having the parameters of an integration machine change without the knowledge of the QA team (e.g. so that changes can be scheduled in, and updates to the testing suites can happen), then the validity of test runs is nullified, testing costs go through the roof, thus adding to the pressure to "skip the tests" and ship / deploy. Ick.
The instructions / script for installing a package on a machine should be EASILY understood by an installer who is skilled in the practice of software installation, and no more. (ie, not written for a senior engineer, not written for the janitor). Enough information to have it properly installed and configured, some basic troubleshooting, and a clear escalation path should issues not get resolved. Skip the 65 pages of configurable parameters if all the installer needs to alter are 12 parameters on the target machines. but don't skip ANY of those 12. If one is missed, find out why. If 10 extra are there, see which ones are needed for the different regions and skip the rest.
My personal line in the sand is the Developer integration area; that stays with the code monkeys. It's important to be able to test out package installs, and this is the type of machine upon which to do it (which is not to say there is a single DIT - have multiple, including one just to test out package installs if need be). QA regions and beyond are under tight control. I work in banks a lot, so Pre-prod and Prod are under a metaphorical armed guard.
Once the installation and config documentation is tested by the developers, the docs get thrown over the wall to the integration team (optimally, QA should be involved in a doc review to make sure that what's in the Doc is what is required, no more and no less). For a Waterfall / SDLC methodology, this documentation review and handover is one of the gating steps. For an Agile / Scrum / XP methology, this can be considered a single story, where the success condition of the task (story, etc) is working installation (works) and usable documentation (has been tested).
The key is not to go bat-crap crazy on it, but to ensure repeatability and workability. It would be GREAT if the install could be automated (or run unattended, or have little or no intermediate steps requiring human intervention) so as to reduce integration errors, but that is dependent on the requirements of those managing the QA regions and above.
Re:Why not use tools that help do it? (Score:5, Informative)
I completely disagree. Developers should absolutely be involved with software installs. Rarely should they have the final say, but both operations and development staff benefit from working together on software installs.
The best example I can give for this is database installs. Working with the operations staff on installs helps developers better understand engine performance. They learn about things like prepared queries, connection pools, what tables remain paged into memory, etc. These are things that help the developers write better code. Similarly, the operations staff can learn what the application focuses are. They can optimize performance through VM provisioning, tablespace layout, memory pool size, etc. They can also understand the usage goals better, which lets them keep developers informed of important changes.
I've been running IT departments for over 10 years, and my experience has shown me that there is a definite benefit to having development and ops work together on installs.
Re: (Score:3)
This is what QA/QC environments are for. And there, developers should be involved in doing the installs. This is where the "hand-off" happens and corrections are made to the installation process.
Re: (Score:3)
This question was not directed as consumer application. It is direct at Enterprise applications. InstallShield just won't do it.
Developers should not install it. Nor should they help install it. If the Configuration Management team cannot do it themselves, then they need to send it back to the developer for better packaging or instructions.
This is to the developers benefit. When new environments are set up, they shouldn't have to contact the developer to deploy the application to those new environments.
And as always. Titles with questions are typically answered with a "no".
Most places I've worked, the auditors would have kitten if the developers directly touched production servers in any way, shape, or form. The really stringent ones wouldn't even accept binaries - all production code had to be compiled and installed from source handed over to the Operations staff.
I often occupied a position where those rules didn't apply to me, but I obeyed them anyway. That way they couldn't blame me.
Re: (Score:3)
all production code had to be compiled and installed from source handed over to the Operations staff.
Which would mean that the Operations staff would also need licenses for the compiler if it is licensed per seat.
In the Best of All Possible Worlds... (Score:2)
Developers -> QA -> Operations (Am I dating myself here?), with the project manager (or Product Manager) driving the process.
I also think developers and QA personnel should be more or less interchangeable, but that's not likely.
I would also insert a second layer of QA consisting of Project Managers and Product Managers. The primary QA guys are running regression tests and unit tests etc. You need to have someone actual sit down and drive the software too because Mercury and the like don't catch everyt
Re: (Score:3)
I would also insert a second layer of QA consisting of Project Managers and Product Managers. The primary QA guys are running regression tests and unit tests etc. You need to have someone actual sit down and drive the software too because Mercury and the like don't catch everything, especially logic and common sense things.
Automated tests are good and I prefer to write automated tests for all the software created by the developers with whom I work. But sometimes interactive tests are useful and/or necessary. Making sure that the core processing routine for your application does what it's supposed to do with known input? Automate that. Making sure that the interface (GUI, web page, etc.) passes the right stuff to the core processing routine when the user clicks on the nice shiny buttons? Harder to automate; it may be more cost
Re:Why not use tools that help do it? (Score:5, Interesting)
I'm sorry, I have a real problem with the underlying assumptions your answer makes about the process. There should not be a high wall between groups. Developers should not install it, but that doesn't mean the developers are not there when QA or Configuration Managment or whoever installs it. As a long-time developer, I learned more from the struggling of other people with my software than all the scaffolding and test-bedding done in isolation. Back when I was doing embedded programming, I made it a point to spend time in System Test to see how my software was being used...and misused. Next to me were the Documentation people, watching out for mistakes or head-scratching -- between us, we would see the holes that needed to be plugged so that the downstream processes would go more smoothly. And I would go out into the field, to customer sites, from time to time, particularly if a customer was reporting problems. This was particularly true of first launches, because sometimes the devils aren't seen until the customer hits them.
This was true for newspaper composition systems, newpaper press controls, bank check processing systems, key-entry systems, even a technical support group application.
I relate this story about the fallacy of compartmentalization: the General Manager gathers all the employees one Friday. Everyone had just been paid, the weeklies and the monthies. GM: "I'm not happy with the 'us versus them' attitude that seems to permeate this company. It's affecting our ability to get product customers want into their hands, so we all can get paid. So, tell you what: everyone pull out their paychecks, and fold them so the signature at the bottom is visable. See? All are signed by the same person. That should tell you something: that we should be working for the same goals, so we all continue to get paid." The change in that company was dramatic: instead of silos, it was more like an open-plan office writ large, with people talking with one another. One side benefit: sales stopped selling what we didn't have, and PARTICIPATED in the creation of new products. That company went from one step from closing it doors to being a booming business. My stock went from $1 to $65 a share. In six months. And the company was in the mid-West, not Silicon Valley
The softball team started doing a lot better, too.
Re: (Score:2)
>And yes it's an Enterprise application.
So, SOP then?
Alternatively ... (Score:5, Interesting)
Developers should concentrate on creating software.
Totally agreed, environments getting screwed up has lead to a lot of sacrificed man hours.
There are already tons of tools that help with the install and configuration state of software. Use InstallShield and the various Visual Studio install and config helpers. Visual Studio itself has many debugger functions available, and there are tons of extra helper plugins if required.
I think that's a bit overkill. Where I work we concentrate on having a unified development environment across boxes. Note that I said environment and not integrated development environment. While the IDE is important, we instead concentrate on maintaining a shell script that points to where things are installed so that there is a commonality in environment variables across boxes. We also like to zip up things that can be just zipped and unzipped and avoid the whole InstallShield mess altogether. So if we're using an agreed upon JDK, we put it in some directory of the zip (like dev/tools/jdkx.x.x) and then in that zip's environment scripts we point at that for JAVA_HOME. Then in Eclipse or Visual Studio or whatever you can tell it to find the preferred java runtime by pointing it at that environment string. In this way, we've managed to keep our development environment diverse with a large toolbox as well as possible to run in Linux, Windows, Cygwin and sometimes OSX (okay, we don't have OSX machines here but theoretically it'd be possible).
Nothing sucks more than sitting down at some coworkers box to help them and saying "What? Why doesn't this command work?" oh, "I guess I don't have that alias" or "I must have a different version of maven" or "I think I'm missing that Ruby gem" or "I don't know, I messed with Visual Studio a bunch and it hasn't worked since." Those are your nightmare scenarios and we try to make our dev box setup wiki page to avoid that at all costs. Two big things to focus on are a common environment and a diverse toolbox.
Re: (Score:3)
Re: (Score:2)
I take it you've not tried to install any major applications on Windows lately.
Let's take two examples I had to do recently.
The first required me to separately install SQL Server, IIS and a few other prerequisites, then install the application, then manually run a SQL script to initialize the tables AFTER manually creating a db instance and authentication parameters, log into the application and configure it to point at the SQL server instance. Not too complicated, but still hardly the simplest method.
The s
Re: (Score:2)
Dev boxes: No, no, no, no and no.
Test boxes: The same.
As an example, If you have 4 developers, there will be 4 different versions of Java in use, and none of them will ever be the corporate standard. Each developer will insist that thier version is "God's own" and force a company wide upgrade, not caring about any other application that requires a specific version.
If developers want to play, they can go home and dev on thier home machine. No problem.
The corporate machine is a machine owned by the corp and m
Re: (Score:2)
Your comment is half way there.
Enterprise software should be installed with something like puppet or cfengine.
the test server(s) should have a script that installs the software from the dev server on a periodic basis (the frequency depends on how long the install takes.) for enterprise software the install should be no more complicated than install-package local-config.txt Otherwise, how the F* are you going to know how the software was installed? The idea of taking days to install software after all th
Re: (Score:3)
for enterprise software the install should be no more complicated than install-package local-config.txt
How can this work if some of the dependencies lack an easy "silent install" feature?
I've been reading "Continuous Delivery" by Jez Humble [amazon.co.uk], which seems to be the bible for this, and the conclusion there is something like
1) Pester the supplier to make a silent install feature
2) Write one yourself
3) Switch to something else (if there's an open source replacement for the software it probably installs silently).
I'm still working out the best way to have a configuration applied to software. I like the idea that the binary should be the same no matter what environment the software is deployed to
Re: (Score:2)
Re: (Score:2)
The devs have worked with the admins to script/automate the installs. The Devs do test installs against their VM images, but the final live install is done by the admins. This also works as a conduit to keep admins up-to-date as to how the software works.
One of the big issues is for our admins to be able to debug basic issues. The admins also give a lot of feedback to the devs on how things seem to be running live.
Re: (Score:2)
That is all fine and good if you are talking about small consumer grade software. But for larger applications installations are not as easy as a wizard.
For the most part you need the following groups.
Team 1: Product Development
1. Programmers They write the code.
2. Developers They write the code too, but they write the framework code for the developers.
3. Architect who give the bigger picture guidance to the Developers a unified say on how things should be done and where they are placed.
3'. Project Manager
Re: (Score:2)
NEVER (Score:5, Funny)
NEVER. Never. never, never, never.
NEVER.
Signed,
Platform and Information Security Architect.
Re: (Score:3)
Seconded.
Signed,
Developer who really isn't very good at that sort of stuff and would rather someone else dealt with it.
Re:Why not use tools that help do it? (Score:4, Insightful)
depends on the software....
In terms of, for example, the web database etc. mentioned in the question you're into a lot of installing an SQL server (that's separate from a developer team generally, but it's a 30 minute job if you know what you're doing), and then building the database. Once you built the database you don't necessarily have an 'installer', you just send them an image of the whole installation (or the whole physical machine).
If you're a company that specializes in making billing software databases then sure, you might have an install script and setup parameters than your installer guys can execute.
There's sort of a hierarchy of techie people. Not everyone at a higher level can do the low level jobs, but one person at a higher level might be able to do all of the lower level stuff in 20 minutes that would take them weeks. This isn't 'consumer' product, in enterprise you might send out a 'linux guy' (who doesn't know linux scripting, that's an advanced linux guy) to do a linux install, but he can be given detailed, line by line instructions to follow from developers. In enterprise 'you' as the development firm can be responsible for getting it installed and setup. And you have co-op students who are basically high school grads following instructions for installations, or you can have a partially automated lab with software engineers running deployment tools to hundreds of machines at a time, it just depends on how big an outfit you are and the sort of customers you have.
Darn (Score:5, Funny)
and I'm not all that familiar with Agile
I'm jealous.
I'm of two minds about this (Score:5, Insightful)
My answer is mostly 'no'. The only benefit I see is that developers will become more motivated to have a simpler and better installation process. And that's a pretty nifty benefit.
But I've been on both sides of the fence. I've rarely been a developer who did anything less than thorough testing before declaring something 'done'. But I know that I'm an incredible rarity in that way. And on the devops side of things, the less ability developers have to push things, the more likely decent QA will get done before stuff ends up in production. But developers frequently also give you installation instructions that are unrepeatable special case installs with rollback instructions that make no sense.
I think that one good way to balance this is to have a preliminary test environment into which developers are allowed to push things. They are given limited rights to this environment, basically just the ability to upload some software and run a deployment script. This encourages them to write functioning deployment scripts. But it prevents them from shoving things into production because it just 'has' to go out today and it's such a small, low-risk thing. Of course it'll work!
Re: (Score:2)
Basically, there are 3 separate but related roles that may or may not be handled by the same person depending on the organization size.
1. A developer is responsible for writing and documenting their code in a way that it can be deployed reasonably easily.
2. A build manager (also called "change control") is responsible for managing and deploying changes to different environments.
3. An administrator is responsible for ensuring the overall health and security of the environments being deployed to.
Ideally, ther
ITIL (Score:2, Funny)
If you're following anything remotely like ITIL, your service transition phase should have an output that includes the processes for use in the operational phase of the service, including installation and upgrade procedures.
My persepctive (Score:5, Insightful)
As a systems administrator, nothing frustrates me more than when a developer sends me an e-mail that says "install this".
First, they do not always say what the software is supposed to do, so I cannot prepare for any security requirements. I am rarely told if it needs a port opened, I have to check the security logs to see if the software is trying to communicate through the network.
Second, while I may have the ability to fix their software, I prefer not to mess with their code or configuration. Since I may not know what their software is supposed to do, I may get it running I do not know if it is operating properly.
Third, if you are asking me to install alpha or beta versions on a live system, it's usually a bad idea. I have no problem installing it on a test server or a VM, but I hate putting it on a production box.
Re: (Score:2)
As a systems administrator, nothing frustrates me more than when a developer sends me an e-mail that says "install this".
Try to see it from the developers perspective. Usually you are someone who expects to be given lots of info, but for security reasons and others (typically that you are staff and the developer is likely to be a contractor, so you can't be bothered) won't tell the developer very important stuff he needs to know about where the software is deployed, including system configuration details, what other stuff is running there and so on.
Also, very often getting a meeting with you is harder than meeting the Pope. When/if the developer gets the meeting you tell him that his software is one of the many you need to deal with (as opposed to him, which one cares about his little program) so you are basically not prepared to accommodate him at all. For example if a library is being used and it needs to be able to have 1024 open files or whatever and your decided someday that he limit was 512, the developer is fucked. Meetings and more meetings, involving bosses, to have that limit raised.
Did anyone bother to mention limits in production that aren't there in dev? No. I'm still waiting to see that kind of requirement detail in any project.
Re: (Score:2)
In some environments, you are 100% correct. Not in my environment, which the developers are not contractors and as the systems administrator I have full control of the boxes, as long as they do not want some sort of terrible security practice (telnet, password123, etc). In a more restrictive environment, you are 100% correct.
When I get the e-mail from a developer, I hunt them down to figure out what exactly is going on, what the software does, etc. Then I bring up the logs, install it, and watch them try
Re: (Score:2)
As a systems administrator, nothing frustrates me more than when a developer sends me an e-mail that says "install this".
First, they do not always say what the software is supposed to do, so I cannot prepare for any security requirements. I am rarely told if it needs a port opened, I have to check the security logs to see if the software is trying to communicate through the network.
Second, while I may have the ability to fix their software, I prefer not to mess with their code or configuration. Since I may not know what their software is supposed to do, I may get it running I do not know if it is operating properly.
Third, if you are asking me to install alpha or beta versions on a live system, it's usually a bad idea. I have no problem installing it on a test server or a VM, but I hate putting it on a production box.
Sounds like a developer's reaction from users who send emails saying "it doesn't work."
I hope you're a fairly small, informal shop, because places where I work require at a minimum, managerial approval before installing anything.
A first-class installer will include the mods to the firewall and system config files (and, ideally, been vetted by someone capable of spotting unauthorized mods). One of the things I like about RPM is that it allows all that, plus the ability to list what was done and validate that
Not all developers are smart (Score:2)
Let's face it, some developers lack IT skills. Most of us have the understanding and appreciation of operating systems, security, and software to manage a safe environment, but some don't.
We also have peculiar environment requirements from time to time, and great need to experiment with different software setups in the course of our work. Engineers will make problems for IT, no matter what. The natural conclusion is to standardize as much as you can, grant admin access where you can't, and be prepared to
On Big Projects... (Score:2)
Developers shouldn't have production access (Score:5, Insightful)
Title says it all - giving a developer access means they can deploy undocumented "hacks" and "quick fixes", usually meaning to document and normalise them later on.
Forcing the, to hand off installation and maintenance to a second team means documentation is enforced, standards are enforced and quick fixes are better vetted.
For the record, I wear both hats in different situations for different clients - as a developer I don't care about the production environment, and I like it that way. I care about the bugs the production environment uncovers, so the UAT environment should be identical, but even then the developer shouldn't have to care about it - that's the systems admin teams job.
Re: (Score:2)
Oh. It's worth noting that my approach is not to consider "Production" as one single environment - typically I recommend the UAT, testing and infrastructure development environments to be classed as near-production, and thus fall under the same restrictions as "production".
I usually give developers their own environment identical to UAT where they have full rights to do whatever in - this allows them to create the full documentation for deployment to production, including permissions changes required etc.
Re:Developers shouldn't have production access (Score:4, Insightful)
I've been in companies that practiced it both ways.
Company A) Developers can never ever access production no matter the reason. The end result in that situation was bugs that couldn't be reproduced on the desktop or in the QA environment. The problems went on for months until I had a lucky break of a developer moving jobs into the system admin role of the production environment. When he looked things over he discovered the previous admin had not configured things in production properly. To the point of lying about it when I had sent a previous check list of things to verify. If I had access to the systems the problem would have been resolved in a few days rather than months.
Company B) Developers own the software and hardware from end to end. In my current company we have to package the software up into a deployment system and deploy it that way. However we do have full access to all the systems. Can/do we do hacks and quick fixes? Yes, if the situation warrants it. But in the end it has to get rolled into the official distribution for it to be correct. Can it be abused? Yes. But that is why the culture of the company become very important. In the end you either trust your developers to do the right thing or you don't. If the company can't trust the developers to have ownership of their code and systems.. Well then at least for me I would say I'm working at the wrong company.
FYI, I enjoy working at company B far more than I ever did at company A. Given a choice I will never go back to an environment where developers don't have access to production.
Re: (Score:2)
But what happens when is the admin of the production environment that does not know what he's doing? And when the developer knows what he is doing but can not do anything because his hands are tied (without access to production)?
Re: (Score:2)
What's "yikes" about that statement? The production environment should be managed by people who have a wider set of goals than "this app should work to spec" - they are looking for deployability, stability, resilience etc etc etc.
As a developer, I should hand them my app, with a documented install routine and set of environment requirements, and the sysadmins should go from there.
Remember, your "production" environment is not one environment - you have identical test, UAT and (very important for large busi
Pros and cons (Score:2)
I've no experience of a company large enough to have a whole separate set of people to do installations, so my comment is from the small company experience.
Problems will get fixed faster if the developer has access to the installation and is familiar with the environment. Live environments are never the same as test environments, so for software above a certain level of complexity there are likely to be site-specific issues.
But it takes a good developer to tread carefully around a live system and to then re
It should be intuitive (Score:2)
NO! (Score:3)
Speaking from personal experience, the last person you want randomly installing software is a developer. You would think that because they work in IT they would know what they're doing, but you would be seriously wrong.
Time and time again I, or the folks I work with, have had to figure out what the developer did when we gave them admin rights to install software and now have a problem. It's tedious, time consuming and generally fruitless as the developer doesn't remember what they did. In the end, we end up having to remove the software anyway and start from scratch, now having wasted two to three times as much effort to do it right than letting a developer do it themselves.
Seperation of duties (Score:4, Insightful)
If it's enterprise class, you have a team responsible for the stability of the servers (support) that is not the same as the developers. Sometimes, you even have a team responsbile for just deployments (depends on size of the org). The developers should have access to install in DEV, but not to TEST. This allows you to test your deployment process (and backout process) before you touch your PROD environment.
http://en.wikipedia.org/wiki/Information_technology_controls [wikipedia.org]
Even if not financial in nature, one of my former employers lumped it all unde SOX compliance.
I used to think yes, but not so much (Score:5, Insightful)
Keep it separate from developers if you can (Score:5, Interesting)
My personal preference as a sr.dev is to have other people do the deployments and verification as much as possible. It never ceases to amaze me how often over looked issues are found just because someone other than the person married to the code is doing things.
My best advice is, regardless of the size of your organization, map out a process on paper and follow it all day every day. You will appreciate the consistency when you get in those situations where a lot of balls are in the air at once.
Separation of Duties (Score:2)
You'd fail an audit if the developers installed the software.
No. (Score:4, Insightful)
-Development happens where they are able to test using a test environment
-Developers hand off everything to the System Admin (SA) who will install it. They then install it on a test environment as well.. If there are issues found work with the developers to solve the issue, correct the documentation and proceed to step 3.
-Install in production.
The only issue with this is step 1 and 2 can sometimes become filled with accusations. SAs think the product sucks and Developers think that the SAs are idiots who need everything spelled out for them. It becomes a lot worst when the developers are contracted out (which is common). This needs to be avoided, both parties should see themselves as working together to create a better product.
Needs to be repeatable ... (Score:2)
Software installs need to be repeatable, and need to be something which can be done by someone other than the devs.
Even for testing, unless you're talking about fully automated testing, it is often good to have someone other than the developer doing the tests. Because in QA if you do something random the developer hasn't encountered or thought of, you can sometimes get very interesting results.
I can't even begin to think of the number of times where a user or QA does something, files an issue, and the deve
Re: (Score:2)
Software installs need to be repeatable, and need to be something which can be done by someone other than the devs
Normally software installation is repeatable no matter what the environment unless you are trying to install software that is being hacked on a daily basis and if that is the case no self respecting System Administrator would allow that software to be installed on anything but what we would call a "Crash and Burn" machine.
As I have have said in a previous post if you are talking about an Enterprise environment then there are allot of things to consider before you as the System Administrator allow software
Re: (Score:3)
I've seen software that gets deployed by the developers ... and it usually comes down to a bunch of manual steps and voodoo they don't share with other people. If you need a dev to instal
Maintainers/Support (Score:2)
Normally I'd much prefer the people actually maintaining and supporting the software to install it in QA and promote it to Production.
This gives them some more knowledge about what they're supporting, and also avoids the 'Just gotta change this' mentality so prevalent in developers :)
Mostly No. (Score:2)
Developers (myself included) are self-assured of their work to the point where they can't be expected to test things thoroughly between the critical points in the timeline when (a) it's done, and (b) it's being used by customers.
The exception to this rule is when a customer has discovered a problem and it requesting a fix because the service "is broken". In cases like this there is a strong desire to minimize the timeline between (a) and (b) so having a short-list of developers who can circumvent/expedit
Situation Dependent (Score:2)
Possible issues with letting Devs do this (Score:4, Insightful)
Just so it's one or the other. (Score:2)
Yes,but not into production (Score:5, Insightful)
You should have at least 3 environments beyond the personal ones the developers use to develop and unit-test code: development common, QA and production. Development common should be where dev does integration tests, including installation. If developers are responsible for creating the installation tools, they should be doing the installations there so they can debug those tools. If someone else is responsible for writing them, the devs should be working with them to make sure the tools do what the software needs to install correctly. You can't get the installation tools right if you don't test and debug them, and when they interact with the software the developers are the best ones to figure out what's wrong and what's needed to fix it.
Developers should not be doing the installation into the QA environment. They should be handing the installation tools over to QA and letting them run then according to the deployment instructions. That's the only way to confirm the instructions were really complete and that everything works per the documentation, by putting it in the hands of people who didn't write it and letting them deploy it. That way when it comes time to deploy in production you've got some assurance that the deployment will work because it has worked before.
Now, if things do go wrong you need dev involvement. They wrote the software and the tools, they'll often recognize exactly what's going wrong where Ops and QA won't. They're also the ones most likely to be able to give you a quick fix to the problem that'll get production up and running without having to back out and try another day. If you've already invested the time bringing the systems down and deploying the new version, it makes no sense to revert to the old version and waste more downtime tomorrow re-doing the deployment if the only problem is a path in a config file having the version number in it in QA but not in production and a quick edit of the newly-deployed copy of the config file will clearly fix the problem.
Re: (Score:2)
Of course! (Score:3)
M.
No, no and for the third time no. (Score:2)
I refer the honourable gentleman to the ITIL guidelines which cover this sort of thing. In brief: developers do not even get access to live systems, much less carry out updates on them.
(Much of this is based on somewhat rusty memories; please correct any mistakes I've made)
Developers package their applications according to an agreed process and hand the packaged application over to an operations team whose job it is to update the live systems.
This update must not be acted upon unless and until the update ha
Heck No. IT/End User feedback loop critical (Score:2)
Having worked at several startups with large environments where development routinely was leaned upon to jump into production I firmly believe that ideally developers should not install their software (or even touch it) once it is released. Allowing them to do so leads to band-aids, hacks, lack of documentation, short-cuts, and all other manners of badness.
Strictly maintaining that division between development and IT/end users helps ensure that development maintains a complete package. Incumbent in that i
Are you kidding? (Score:2)
Developers shouldn't even build software for customers/production.
make is 35 years old!
make
make install
Not having an automated build and install process is a waste of everyone's time, but especially the developers' time.
Shouldn't really matter (Score:2)
caveat - this is talking about as the poster requested, production deployment of web services from big companies.
The software should be able to be deployed by nearly anyone familiar. Any changes to deployment are modifications of install scripts or applications.
Actual deployment to a production environment should be able to be done by a lot of different roles.
I prefer not to have developers deploy because they have access to a lot of different possible packages.
Build should be produced by CM.
Test should be
Someone has to install it (Score:2)
If your developers have time to spare and are salaried then it might make sense to have it be part of their jobs. If it can be done by someone cheaper or less critical to tight developer deadlines then you might have it be a job or a role in some other job.
I don't see anything inherently wrong with having some developers in that role though.
Hands off the production environment. (Score:2)
Ideally, the systems management team should handle install into staging and production environments. They have worked with the dev team to establish a standard environment. The dev team should take time to understand the environment where the application will be deployed, and the systems team should understand the application well enough to diagnose basic problems.
Unfortunately, in my experience, cost cutting means that the installation and maintenance is done by an IT contractor pulled from a rotating po
Dev should not every touch the prod environment (Score:2)
Where I work developers do not have any access to production. We have a process and it tries to ensure that what gets to production has been tested by the dev team, reviewed by the support team, and finally tested by the client before it even gets near the production machine. The devellopment team defines what is to be added/changed/deleted (specs). The support team and client approves the changes before we start. The code is then tested and signed off by everyone. Once that code is ready the developm
Yes, when they do, they produce good software (Score:2)
I have been with this company since we were very small, pre IPO days. Those days, we did not have a separate QA dept and we devs pitched in as QA and documentation. Many routine stupid things to do QA kept getting in the way of what we believed as our true job, develop code. So we wrote stuff in the product to ease our own QA.
For example Win98 introduced a "preview" pane on its file explorer. We had our own file explorer, and we had a preview
it depends (Score:2)
My huge company with many brands has 100s of web sites. We have a few classifications of sites, and each classification has it's own process. In some cases (e.g. credit cards involved), it MUST be deployed & operated by a 3rd party vendor (different than the developer). In other cases, a single (approved) developer can do everything him/herself, as long as it's coordinated with the brand manager and corporate PR and has no features corporate privacy or security teams would object to and is hosted at
End users should be able to install the software (Score:2)
How big an enterprise? (Score:2)
For very large corporations, backend deployments are few. Frontend deployments are many. I'd say developers who know their backend environment, which changes little, can be trusted in deploying what they develop - with supervision and prior auditing by those entrusted with maintaining the environment. Absolutely not in the case of frontend deployments, where you may see many different configurations hardware-wise. Something which works on one box might bring another box down - workstation administrators are
tsk (Score:3)
it seems unhealthy to me to have software installs done by developers
"unhealthy" is putting it very nicely. It's insane.
The developers should never have to touch the production system. It is very, very important that the guys running the production system know how to install the software on it and get it up and running. That is exactly what they will have to do if everything burns down one Friday night.
Plus having the developers install it is an open invitation for all kinds of hacks and shortcuts instead of a proper deployment process.
human interaction (Score:3)
probably not (Score:2)
If this is software only used internally, you may not have a choice. Unless the department is large enough to include an administration group, developers may not have any choice. But everywhere I've seen this, it's been a bad practice. Developers are good as developers. It is not necessarily in their skill set to be administrators and system architects also.
For software intended to be sold, it is *very* bad practice for developers to be responsible for installation on QA (especially QA!) and final test.
Headline question? Answer is no. (Score:2)
There's a balance (Score:2)
Part of having a validation team is to approach the code without the biases of the developer. The developer is too intimate with their software, and on top of the two primary methods for code coverage (random and directed tests), there is still the human element that a validation team brings.
On the other hand, it is also useful for a developer to "eat their own dogfood". I wrote CAD tools for a decade, and when I finally became a designer and actually USED them I was like, "Dafuq did I code this stupid fe
It shouldn't be an XOR (Score:2)
Yes, the installation process should be relatively automatic, and well documented so that another team can and should usually install it. However, such teams are often *too* capable, that is the Developer(s) should do some installations themselves so they see just what sort of nightmare they have created ... or how fragile it is in the context of a full production environment.
Development environments are no substitute for the RealWorld. Ignoring the RealWorld is a BadThing
Production Environments? Absolutely not. (Score:2)
Should developers be responsible for installing the software they develop into production environments?
Absolutely not. This is horrible security practice and will not fly even an inch in many industry standard audits. I can give countless examples. A developer sneaks a change into the software to funnel personal information and credit card numbers off to a private database and then sells it on the black market.
The whole point behind the division of labor is a set of checks and balances and reduction in conflict of interest. Quality Assurance analysts validate the code does what it is supposed to. The de
Three thoughts (Score:3)
On developers never having access to production:
In many cases, developers are the only people who understand the full application, and in many cases are the only people who can actually troubleshoot a botched install or figure out why things aren't working right in production. Yes, you are suposed to have some kind of QA or staging environment and you are not supposed to deploy bad code, but sometimes things go sideways. In these cases, only a developer who knows the code and any integration issues will be able to figure out what went wrong. Acting like developers should *never* have access to production is a lot like saying "the mechanic should never have access to my car's engine, ever". It makes sense 99.9% of the time, but there is a .1% where your engine is broken and the mechanic can't fix it without getting under the hood. Yes, Mr. System Administrator you can change your oil, rotate tires, and even change wiper blades but fixing a spun road bearing or smoked transmission solenoid is flat out.
On Developers and Access Rights:
There are a lot of developers who don't understand the computer they are developing software on. Usually, they are very BAD developers. Take for instance, a webdev who doesn't know Apache. Instead of using built in tools like mod_rewrite, the developer will build their own tools to do what is built in to apache. Good developers know their platform, often at a level that is much deeper because they take time to read code or API and config documentation so they understand the toolbox they are working with. Often a single line of configuration is more powerful than 1000's of line of code. Developers need to be administrators on at least their developement environments... usually extended to staging there is a large difference in scale between development (a VM on my laptop) to staging (multiple servers) and production (hundreds of servers).
On installer driven software:
It doesn't matter if you use installshield, roll your own RPMs or use Salt, Chef or Puppet. Any way you go you should do everything you can to automate installation. When you automate you reduce the chance of human mistakes in installation process. If you do installation automation right, then a deploy to production can be triggered by anyone with appropriate authority or any automated process with appropriate authority. Having people sit at the console and install software manually should be a red flag that the software you are buying sucks or is incomplete.
In Enterprise-Grade software:
Installatioin should be automated to the maximum extent possible, using the appropriate operating system installation tools. Documentation for the upgrade and install should be clear enough that a non-developer can successfully install and test the installation. Install activity should be logged, so that if something does go wrong, it can be figured out later.
yes but there are exceptions. (Score:4, Insightful)
Creating the flawless installers costs time.
Time means money. If the software is only installed twice (on test system and production), a good flawless installer is very expensive. If it is installed a lot of times (more than 5 systems), automation of the installation will pay itself.
Generally it is good practice to keep the developers out of the production environment.
However there must be exceptions.
-Emergency fixes.
-If there is no good team of maintainers, you can actually look at the installation logs, and understands them, the developer might be the better option. A good maintainer, who only blindly runs a script is not the best option.
-Uptime might be more important that the principle.
Re: (Score:2)