Forgot your password?
typodupeerror
Programming

Ask Slashdot: Should Developers Install Their Software Themselves? 288

Posted by samzenpus
from the hoisting-with-your-own-petard dept.
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."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Should Developers Install Their Software Themselves?

Comments Filter:
  • Developers should concentrate on creating software. 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.

    Developers should use those and make sure users can install their software themselves.
    • by Bigby (659157) on Monday September 24, 2012 @11:16AM (#41437255)

      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".

      • by macbeth66 (204889) on Monday September 24, 2012 @11:23AM (#41437381)

        ::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.

        • by udachny (2454394) on Monday September 24, 2012 @02:30PM (#41440493) Journal

          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?

      • by Rhaban (987410) on Monday September 24, 2012 @11:29AM (#41437509)

        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)

        by bluefoxlucid (723572)
        If the developers don't dogfood it, they won't understand wtf is the problem. Make them install that shit themselves, make them watch the end user install it, make them fix it when the end user fucks it up because they don't know the formula for the secret sauce. Get that secret sauce shit out of there and give me something straight forward.
        • by rthille (8526) <{gro.tagnar} {ta} {todhsals-bew}> on Monday September 24, 2012 @11:34AM (#41437595) Homepage Journal

          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.

      • by ccguy (1116865) on Monday September 24, 2012 @11:41AM (#41437707) Homepage

        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)

          by Anonymous Coward

          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.

          • by ccguy (1116865)

            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?

        • by Imagix (695350) on Monday September 24, 2012 @12:09PM (#41438193)
          Getting a developer to see the installation process is not the same as having the developer do the install as a matter of course. One is a debugging process, the other is development. If Dev and Prod aren't identical, then their Configuration Management team has failed. They need to learn that Test (and to an extent Dev) are just as important as Prod.
          • by ccguy (1116865) on Monday September 24, 2012 @12:18PM (#41438377) Homepage

            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".

            • by Imagix (695350) on Monday September 24, 2012 @12:30PM (#41438597)
              You didn't understand the beginning of my post. Having the developer watch is not the same as having the developer do the install. Read-only vs. read-write. I'm OK with dev being able to read-only. They can't "infect" production with their assumptions if they can't change anything. If they find something that needs adjusting then they should be adjusting their own environment to replicate the problem (or simulate it if necessary), construct the fix, then communicate the fix to those who should be doing changes to Test and Prod. If Dev and Prod aren't the same for whatever reasons, then the powers-that-be have to understand the costs that are incurred by not having them the same. You save the $5k on using cheaper hardware in Dev, but cost them $50k in downtime because that difference causes a bug to be exposed in Prod. (Picking numbers out of thin air). And yep, sometimes that $5k savings does end up really being $5k in savings as the difference in hardware had no impact on the environment. It's something that needs to be considered. (And yes, I'm very firmly on the development side of the fence, and my software gets installed into large production environments that I will never see, and in some cases am not legally allowed to see. Something about foreign nationals not allowed to touch or see any hardware that controls satellites...)
              • by SQLGuru (980662) on Monday September 24, 2012 @01:16PM (#41439365) Journal

                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.)

        • 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

        • by miltonw (892065) on Monday September 24, 2012 @12:23PM (#41438469)

          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.

          • by ccguy (1116865)

            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

            • by miltonw (892065) on Monday September 24, 2012 @01:16PM (#41439381)

              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.

      • by landoltjp (676315) on Monday September 24, 2012 @11:52AM (#41437873)

        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.

      • by punker (320575) on Monday September 24, 2012 @11:52AM (#41437897)

        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.

        • by Bigby (659157)

          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.

      • 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.

        • by tepples (727027)

          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.

      • 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

        • 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

      • by satch89450 (186046) on Monday September 24, 2012 @12:35PM (#41438671) Homepage

        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.

    • Alternatively ... (Score:5, Interesting)

      by eldavojohn (898314) * <eldavojohn.gmail@com> on Monday September 24, 2012 @11:22AM (#41437371) Journal

      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.

      • Yeah, all those zips and tarballs are why I cringe when installing enterprise software. The upgrade cycle is vicious and spotty, and when the dependencies change things break in unpredictable ways.
    • by gman003 (1693318)

      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

    • 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

    • by micheas (231635)

      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

    • I don't know what my point is but every day I deal with Java devs that don't know the difference between the JDK and JRE, let alone how to actually install either of those. If the IT department doesn't configure their IDE of choice, if they screw up their config settings, they grind to a halt and work simply stops. Sure they can write code well enough, but what good is that when the same devs need to troubleshoot an app server issue at a client site.

      Maybe I'm becoming more BOFH like the older I get, but is

    • by Bengie (1121981)
      I'm not saying this is the "best" way, but this is how it's done at my work.

      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.
    • 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

    • by magisterx (865326)
      It depends. When we are talking about desktop applications (whether consumer or purely in-house), then there should certainly be a user friendly install package for everyone's sake. It makes it easier for the front-line help-desk, easier for the user, and saves the developer time. For complex server packages, I would be much more tolerant of not creating a simple install package. For something like that, creating a simple install package might be very difficult and might loose the ability to customize e
  • Darn (Score:5, Funny)

    by Anonymous Coward on Monday September 24, 2012 @11:12AM (#41437191)

    and I'm not all that familiar with Agile

    I'm jealous.

  • by Omnifarious (11933) * <eric-slashNO@SPAMomnifarious.org> on Monday September 24, 2012 @11:14AM (#41437219) Homepage Journal

    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!

    • by dkleinsc (563838)

      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)

    by Anonymous Coward

    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)

    by Sparticus789 (2625955) on Monday September 24, 2012 @11:17AM (#41437277) Journal

    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.

    • by ccguy (1116865)

      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.

      • 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

    • 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

  • 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 intalliation is team effort that takes several hours over a weekend to install at one location. On some projects building the application is a full time job for a "build" lead.
  • by Richard_at_work (517087) <richardprice.gmail@com> on Monday September 24, 2012 @11:18AM (#41437303)

    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.

    • 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.

    • by JASegler (2913) <jaseglerNO@SPAMgmail.com> on Monday September 24, 2012 @11:49AM (#41437807)

      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.

      • I totally agree. By the comments above I suspect that the problem is actually the lack of quality developers, if you only have "script kiddies" then makes sense to keep the production environment away from them.

        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)?
  • 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

  • If the dev team did their job right, installation of the software should be easy enough to have no more than a one page instruction sheet with some basic guidelines. Even horribly complicated apps, like a client/server AV, can be deployed on a network with minimum fuss when the software is built right. If I'm having to go in and adjust registry settings manually for your software, your development team is doing it wrong.
  • by smooth wombat (796938) on Monday September 24, 2012 @11:21AM (#41437361) Homepage Journal

    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.

  • by SQLGuru (980662) on Monday September 24, 2012 @11:21AM (#41437365) Journal

    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.

  • by nick_danger (150058) on Monday September 24, 2012 @11:24AM (#41437405)
    There was a time in my career that I'd have said yes, the developers make the most sense as they are the only ones that really understand the process. But now I know that's exactly the problem with having developers doing the installs. For a production system you need to have a well defined process that produces repeatable results. The only way to ensure that is to have a separation of duties, whether it's an administrator that's being intelligent hands for a human-readable script, or is simply kicking off a developer provided computer readable script.
  • by trybywrench (584843) on Monday September 24, 2012 @11:25AM (#41437423)
    What we do at my company is allow the developers to work with the project managers and deploy their applications out to a test environment for client facing review and acceptance as often as they like. This lets us do new test deployments quickly and easily with no red-tape. Once the project is a go for production then a formal request is made to move to the production server farm. The main guys in Ops, Dev, and the PM are brought into a meeting and make sure everything is taken care of ( SSL certs, DNS, monitoring, load balancing, number of nodes, etc ) then a go, no-go decision is made on the deployment. Once it's been decided that a production deployment is ready then the actual task of deploying the application is assigned to whoever wants it (usually the team lead) since the process of deploying to production is identical to deploying to test in our environments. Also, we use our continuous build server (Hudson) with a production maven profile for actually retrieving the war that is going to the server farm (i do Java web apps).

    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.
  • You'd fail an audit if the developers installed the software.

  • No. (Score:4, Insightful)

    by dremspider (562073) on Monday September 24, 2012 @11:26AM (#41437447)
    When the developers leave and their is no documentation and the thing blows up... No one will know how it works. With handing the product and the documentation off to someone else this provides a final check on the documentation to ensure that the documentation doesn't suck. Developers tend to intimately know their product well and therefore will be likely to leave out steps in the documentation, because they know how to do it anyway. I have seen this a number of times. When they leave it takes reverse engineering to figure out what was done. I am a big proponent of documentation. Here is how I think it should be done:

    -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.
  • 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

    • by donaldm (919619)

      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

      • by gstoddart (321705)

        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.

        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

  • 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 :)

  • 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

  • I think this is one of those situations that is really very context dependent... it will depend on things like how isolated the two teams are from each other, how frequent updates are rolled out, etc. You want a good process in place, but where individuals or groups fall across the process really comes down to 'what will work best in the situation as it is'. Even large(ish) scale operations you might have people wearing multiple hats and strong dividing lines would only make things less efficient.
  • by Zontar_Thing_From_Ve (949321) on Monday September 24, 2012 @11:29AM (#41437505)
    I work for a (mostly) US based Fortune 500 company who for various reasons I would prefer not to name. Short story - if you are a big enough company that external auditors come to visit you (we are) and your Dev people install code, even in test environments, you may fail an audit in the USA. Trust me, it is bad for business to fail this kind of audit. I'm in a system admin type job and a bit isolated from the workings of our Dev group, but it's my understanding that we run Agile or some variation of it and we absolutely do not allow Devs to ever install code in test or production environments.
  • If you're going to lock me out of the production environment (which I prefer, thank you), don't call me on the weekend if something isn't working! On the other hand, if you need me to install, get out of my way and let me work. I'll just build a tool that does the job so I can go home. It should be a repeatable process, anyways.
  • by Todd Knarr (15451) on Monday September 24, 2012 @11:32AM (#41437571) Homepage

    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.

    • This. We do the same thing in our environment. Devs have almost total control over the dev systems, we have an easy means to refresh/wipe out said systems if and when the devs screw it up, and when it's ready for actual users to test the business analysts (working closely with the devs) ship it over to QA for client testing. If the clients approve it then a formal request is drafted for operations to install it in production. The has drastically reduced the number of errors that slip into production (th
  • by blirp (147278) on Monday September 24, 2012 @11:33AM (#41437579)
    But only the two or three times to perfect the automated procedure.

    M.

  • 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

  • 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

  • Developers shouldn't even build software for customers/production.

    make is 35 years old!

    ./configure
    make
    make install

    Not having an automated build and install process is a waste of everyone's time, but especially the developers' time.

  • 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

  • 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.

  • 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

  • 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

  • This is just anecdotal, but has some good reasoning behind it.

    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

  • 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

  • I work with Industrial Automation Software. I have developed the software and installed it a customer sites. Any customer that depends on the vendor to always install the software is courting disaster. What if your critical enterprise software is custom installed, runs for five years and then due to a hardware failure you need to reinstall from scratch? Will the original person who did the install still be available? Is the software still being supported? All end users should have explicit written instructi
  • 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

  • by Tom (822) on Monday September 24, 2012 @11:59AM (#41438027) Homepage Journal

    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.

  • by phantomfive (622387) on Monday September 24, 2012 @12:02PM (#41438055) Journal
    I'm not sure a human should be installing anything manually on production environments. Upgrades should be done automatically.
  • 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.

  • Huh, another example of how almost any question that appears in a Slashdot title should be answered with "no". No, the developers should not install the software themselves. Not in test, not in production. (Assuming a sufficiently large company that there are people other than the developer...) It shouldn't be that hard to install and get the software up and running. Should something happen to the developer (quit, fired, Hit By A Bus, whatever), who's gonna install it then? At a minimum, there's a bu
  • 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

  • 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

  • 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

  • by salesgeek (263995) on Monday September 24, 2012 @04:55PM (#41442637) Homepage

    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.

The flow chart is a most thoroughly oversold piece of program documentation. -- Frederick Brooks, "The Mythical Man Month"

Working...