Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Should Developers Install Their Software Themselves?

samzenpus posted about 2 years ago | from the hoisting-with-your-own-petard dept.

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

cancel ×

288 comments

Sorry! There are no comments related to the filter you selected.

Why not use tools that help do it? (2, Informative)

AE90 (2737939) | about 2 years ago | (#41437171)

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.

Re:Why not use tools that help do it? (0)

Anonymous Coward | about 2 years ago | (#41437205)

What a silly attitude. If the users cannot install the software, the developers will soon be out of a job.

Re:Why not use tools that help do it? (0)

Anonymous Coward | about 2 years ago | (#41437209)

Shht. I think this is about a linux mess, not a windows one ;-)

Re:Why not use tools that help do it? (0)

Anonymous Coward | about 2 years ago | (#41437369)

For context, I'm talking about enterprise grade, Internet facing web services

So no, obviously not Windows.

Re:Why not use tools that help do it? (5, Insightful)

Bigby (659157) | about 2 years ago | (#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".

Re:Why not use tools that help do it? (4, Informative)

macbeth66 (204889) | about 2 years ago | (#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.

Re:Why not use tools that help do it? (5, Insightful)

Rhaban (987410) | about 2 years ago | (#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:Why not use tools that help do it? (1, Insightful)

bluefoxlucid (723572) | about 2 years ago | (#41437513)

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.

Re:Why not use tools that help do it? (5, Insightful)

rthille (8526) | about 2 years ago | (#41437595)

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:Why not use tools that help do it? (4, Interesting)

ccguy (1116865) | about 2 years ago | (#41437707)

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:Why not use tools that help do it? (2, Informative)

Anonymous Coward | about 2 years ago | (#41437915)

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:Why not use tools that help do it? (1)

ccguy (1116865) | about 2 years ago | (#41438153)

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? (4, Informative)

Imagix (695350) | about 2 years ago | (#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.

Re:Why not use tools that help do it? (0)

Anonymous Coward | about 2 years ago | (#41438217)

In our environment, the developers can't get close to the production servers - or even the QA servers or test servers. The QA/test team cannot get close to any of those servers as well. However, the QA/test teams can intiate a deployment process to push an application to the QA or test environment servers (forcing a deployment process to be defined for new apps before new apps get delivered). We have tools/scripts that compare aspects of the machines across environments to flag machines that are not identical where they should be. This enables the environments to be kept in sync with library versions, software packages, etc.

For each of the test, QA, and production environments, we have a dedicated server with debugging tools set up (that also gets applications deployed to it) that don't take regular traffic (real clients in production and QA/test clients in QA/test) so that if a developer can't reproduce a problem on their own machine, they can reproduce and debug an issue in the environment that it's occurring in (and using all the same shared resources). We actually go to the extreme and give each developer a machine that's configured like all test, QA, and production servers (no developing on laptops/workstations). We don't restrict software from being added or upgraded, but we have the same validation capabilities to identify differences between their machines and a server in test/QA/production.

This is all done primarily in support of web applications, but there are some services (Windows services) or console apps that are supported this way as well. Developers absolutely don't need access to servers in any environment - it seems to be used as a shortcut or maybe a cost-savings measure to having good process and architecture.

Re:Why not use tools that help do it? (0)

Anonymous Coward | about 2 years ago | (#41437817)

What Configuration Management team? ;)

I debug it, write code for it, install it, document it, support it (email+phone+ etc), attend meetings about it. And it's a legacy system based mainly on .Net 2.0.

Before I took over, the source control was Visual SourceSafe and the commits didn't have comments and were done like twice a month/year or something.

And yes it's an Enterprise application.

Re:Why not use tools that help do it? (1)

FithisUX (855293) | about 2 years ago | (#41437851)

Have you heard about Chef?

Re:Why not use tools that help do it? (4, Insightful)

landoltjp (676315) | about 2 years ago | (#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.

Re:Why not use tools that help do it? (4, Informative)

punker (320575) | about 2 years ago | (#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.

Re:Why not use tools that help do it? (2)

RabidReindeer (2625839) | about 2 years ago | (#41437971)

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.

Alternatively ... (5, Interesting)

eldavojohn (898314) | about 2 years ago | (#41437371)

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:Alternatively ... (2)

bluefoxlucid (723572) | about 2 years ago | (#41437539)

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.

Re:Why not use tools that help do it? (1)

gman003 (1693318) | about 2 years ago | (#41437421)

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 second required me to manually install several odd prerequisites (IIS (despite not being a web package), the IIS 6 compatibility plugin (despite requiring Windows 8/2008R2, which only use IIS 7), ASP (again, it doesn't run a web interface), .NET 4.0 runtime, and Acrobat Reader (no PDFs were included)). Then I could install the "prerequisites package", which mainly consisted of drivers for the security dongle. THEN I could install the actual application, which had thankfully managed to complex task of "initializing database tables". There's more that I still have to do, but I can't figure out what they are because they didn't include the installation manual anywhere.

These are both major, multi-billion-dollar applications (the first one has options for using SQL Server or Oracle), proprietary as fuck, shipped out on custom-printed DVDs, and yet they can't manage to make an installation that takes less than a full day.

Re:Why not use tools that help do it? (1)

nosfucious (157958) | about 2 years ago | (#41437465)

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 must follow the rules.

If there is ever a fantastic reason to upgrade, then the business case has to be put, and approved. Not simply because the developer used that version and seemed ok at the time.

Re:Why not use tools that help do it? (1)

micheas (231635) | about 2 years ago | (#41437573)

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 the config questions are answered is crazy, but all too common.

Re:Why not use tools that help do it? (1)

digitalchinky (650880) | about 2 years ago | (#41438103)

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 it really too much to expect anyone above software associate to know their way around simple systems administration tasks? Documentation is not difficult, writing an S.O.P for the IT support staff is even easier. Anyone calling themselves a developer that can't do this, or has a team to do this for them, well, I don't have that luxury and I'd bet that makes for a huge difference in salary, one person instead of 4 to do the same job.

 

Re:Why not use tools that help do it? (1)

Bengie (1121981) | about 2 years ago | (#41438113)

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.

Re:Why not use tools that help do it? (1)

jellomizer (103300) | about 2 years ago | (#41438157)

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 works parallel with the Architect to make sure the project is moving at the right time and deals with management.
4. Management they give the business case that needs to be solved and approves solutions from the Architect and Project Manager.

Team 2: Product Implementation.
1. Support Group: They do the physical install to the system. Often called Consultants/Contractors...
2. Implementation Designers: They design the workflow needed to install the documentation
3. Technical Writing: Their job is to document the application and work with Team 1 to get the information.
3'. Project Manager works with Technical Writters and gives insturctions to the Implementation designers.
4. Management (This could be part of Team 1) In essence a way to keep the two teams in sync.

Now this is for a setup of a large complex project, where the Install is more then just a wizard click away. But installing the software, getting the configuations correct and dealing with the customers.

Most of Team 1 should be kept away from the customers, because the customer will often want to deal with them, and bypass Team 2, as Team 2 is considered less technical, and will often say Yes this version can do it or No. And try to pressure team one to keep on custom configure code to do what they wan't... This could corrupt the project, Because the project if done well should be following best practices, and the customers want to just do it the way they did it in the past.

Darn (5, Funny)

Anonymous Coward | about 2 years ago | (#41437191)

and I'm not all that familiar with Agile

I'm jealous.

Key Sentence (1)

Anonymous Coward | about 2 years ago | (#41437213)

"I'm talking about enterprise grade, Internet facing web services sold to end users"

If it is a web application, and if they are internal customers - if the software is being written by one department of the company for other departments to use - and if the software is properly documented by the developers, I don't have a problem with the developers deploying it.

Otherwise, um, yeah, the deployment/installation manual should document it well enough for an outsider to be able to install it.

I'm of two minds about this (4, Insightful)

Omnifarious (11933) | about 2 years ago | (#41437219)

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:I'm of two minds about this (1)

Anonymous Coward | about 2 years ago | (#41437337)

I agree with this. I am a Web Application Development Team Lead and this is what I push for. You need to have one system that you can deploy to so that you can actually test the deployment, but after that it should be handed off and only the deployment script should be needed to deploy it.

In my company, we don't have this hand off, although I would really like to have it.

Re:I'm of two minds about this (1)

hawkbat05 (1952326) | about 2 years ago | (#41437339)

I'm mostly in agreement with Omnifarious. I've seen developers who are actually incapable of following the same instructions provided to customers to install the software they work on. Developers should definitely be put in the end Admin's seat once in a while, I don't think it should be a permanent thing though. It should be seen as a learning experience for the developer in UE.

ITIL (2, Funny)

Anonymous Coward | about 2 years ago | (#41437249)

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 (5, Insightful)

Sparticus789 (2625955) | about 2 years ago | (#41437277)

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:My persepctive (1)

ccguy (1116865) | about 2 years ago | (#41437837)

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:My persepctive (1)

Sparticus789 (2625955) | about 2 years ago | (#41438105)

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 to use the software. I use the logs to find any settings which have to be changed, usually changing them before the developer even e-mails me.

Re:My persepctive (1)

Ravaldy (2621787) | about 2 years ago | (#41437973)

I disagree with the BETA comment as in most enterprises I have worked in, there comes a point where new internal software needs to be tested by the actual users for proper feedback to be received before final deployment. Refusing to install BETA versions in a controlled test environment is just plain dumb and hinders the progress of such project.

It depends (1)

stackOVFL (1791898) | about 2 years ago | (#41437285)

In the straightforward case a distribution package should be made and that could be used by just about anyone to install the software (SW). In other cases, depending on the target system, it may be more technical. If the SW interacts with other SW (like a database or some data collection app) quality checks must be completed to ensure the overall systems stability. There are also platform specific issues to be concerned with. It's also a very good idea in some situations to have the developer install the application as they should be performing other quality control steps (like cleaning temp files and other old log files).

Not all developers are smart (1)

i kan reed (749298) | about 2 years ago | (#41437289)

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 put out some fires.

On Big Projects... (1)

ZombieBraintrust (1685608) | about 2 years ago | (#41437299)

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.

Developers shouldn't have production access (5, Insightful)

Richard_at_work (517087) | about 2 years ago | (#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.

Re:Developers shouldn't have production access (1)

Richard_at_work (517087) | about 2 years ago | (#41437395)

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 (0)

Anonymous Coward | about 2 years ago | (#41437559)

as a developer I don't care about the production environment,

Yikes.

Re:Developers shouldn't have production access (1)

Richard_at_work (517087) | about 2 years ago | (#41437797)

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 businesses) business continuity environments. The bones of these environments are something that a developer shouldn't care about - its the systems team that sets them up and manages them, the developer just has a set of requirements to hand them for his app.

If the app runs in development but not in production, then that's a bug to be resolved, and ideally should be resolved on the developer end wherever possible because you do not want highly custom environmental changes for individual apps - that creates huge maintainability issues further on down the road.

Re:Developers shouldn't have production access (3, Insightful)

JASegler (2913) | about 2 years ago | (#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.

No way (1)

Anonymous Coward | about 2 years ago | (#41437319)

Separation of duties is important. Developers should be developing. Release people should be releasing, and there should be controls around that.

yes but there are exceptions. (3, Insightful)

leuk_he (194174) | about 2 years ago | (#41437477)

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.

Pros and cons (1)

pr0nbot (313417) | about 2 years ago | (#41437341)

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 retro any fixes back into the code base and test it. A methodical release/report/debug/fix/rerelease cycle -- whether or not it's the developer doing the installing -- might be slow and tedious but will have a lower chance of regression errors. It depends very much on whether the customer can afford/tolerate the time and disruption to live systems involved.

It should be intuitive (1)

sandytaru (1158959) | about 2 years ago | (#41437347)

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.

Depends on the IT environment (1)

Anonymous Coward | about 2 years ago | (#41437349)

I work as a Business Analyst in a large insurance centric company. We have developers that write or supervise other developers, DBAs that manage a large database and a staff of developers responsible for installing everything from Microsoft updates to custom code for both client facing (web based applications) to internal locally installed applications. I have seen that each silo can be either a help or hinderance to the process. I invite developer or deploy specialist to come into my area during the deploy process, this has immensly helped their understanding of the unique situation faced by each business area. Smaller operations would surely have different needs.

No. (0)

Anonymous Coward | about 2 years ago | (#41437359)

No.

NO! (2)

smooth wombat (796938) | about 2 years ago | (#41437361)

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 (3, Insightful)

SQLGuru (980662) | about 2 years ago | (#41437365)

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 (4, Insightful)

nick_danger (150058) | about 2 years ago | (#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.

Keep it separate from developers if you can (4, Interesting)

trybywrench (584843) | about 2 years ago | (#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.

Separation of Duties (1)

Kookus (653170) | about 2 years ago | (#41437441)

You'd fail an audit if the developers installed the software.

No. (3, Insightful)

dremspider (562073) | about 2 years ago | (#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.

Needs to be repeatable ... (1)

gstoddart (321705) | about 2 years ago | (#41437451)

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 developer says "well why would you do that?" thinking it absurd someone would have deviated from their carefully plotted out use case.

People develop their own blind-spots to the software they work on, and tend to use it the way you're "supposed" to, and then they miss some corner cases where you do something totally unexpected.

IMO, if you need your developers to install in Prod, your software is a little on the creaky side and it isn't going to work well for customers. If you need a developer to install it, either you're going to be deploying it in a small number of environments (making it ridiculously annoying to maintain), or there's something broken about how you install.

Puppetize, Puppetize, Puppetize (0)

Anonymous Coward | about 2 years ago | (#41437455)

With the somewhat bigger, more enterprise-y applications hardware and application simply depend on each other in terms of availability, performance and scalability. Therefore, placing this responsibility at just one team (be it developers, be it administrators) will never work. What we've done is use Puppet to automate all server installs (Chef could be an alternative). Every system from development (relying on VirtualBox and Vagrant) to Production uses puppet. A developer simply writes the puppet manifests he needs to get the software working. Then, that is reviewed by the administrator (or devop, so you wish) who may also optimize it here and there for the relevant environments. Once both sides of the game agree, the new puppet manifests are deployed across the relevant environments together with the application itself.

This also ensures that on development the same configs are used as they are on production (although on development you'll hardly ever replicate an e.g. load balanced setup).

Lesson Learned: No (0)

Anonymous Coward | about 2 years ago | (#41437459)

I have been in various enterprise environments as a developer and I would have to say the best environments had a deployment team who were responsible for this.

By having a team/person responsible for application installation/upgrading they can focus on the responsibility of ensuring things are properly backed up and that installations can be timed properly. By knowing the state of the production servers they can make informed choices about what is going on and typically have the permissions to view logs/set permissions/make server configuration changes that a developer should not have permissions to. This leads to less problematic installations/upgrades I have found.

By forcing having a documented installation procedure (and post installation configuration too) the deployment is repeatable. If the developer is gone and the application needs to be installed on another server how does someone know what to do? By having that documented and packaged as one unit it should be relatively easy to install ten years down the road if need be.

Another thing I have found with developers deploying is that they may shoehorn a project in. Some examples are turning on debug messages to diagnose a problem and never turning it back off which can be a security issue. They may also patch things on the fly without documenting that, the next person to deploy may not know that step was done and overwrite a change or run into the exact same issue without knowing what was done to solve it the first time. This can end up being very wasteful.

Maintainers/Support (1)

splutty (43475) | about 2 years ago | (#41437471)

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

Risk Management, Baby (1)

benzaholic (1862134) | about 2 years ago | (#41437473)

Deployability is part of maintainability, and this should have been at least touched upon in the Requirements. Since this is "enterprise grade" stuff, there is almost no legitimate excuse for not doing so. Plan it into the project, including finding appropriate development resources.

We'll assume for many reasons that this is not a Windows-based package, but it can still be bundled into versioned installable packages appropriate for the operating system, or at the very least use WAR packages to deploy web app updates.

If the standard production deployment technique is too complex, it becomes its own significant risk area in the product. It therefore requires that QA test the Dev-provided deployment, upgrade, and rollback procedures in test or staging environments.

Or you can just Cowboy it and take your chances.

Mostly No. (1)

rwv (1636355) | about 2 years ago | (#41437475)

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/expedite the formal test/release process in these cases is a good thing.

But yeah... for scheduled upgrades of software that "must work" you've got to put QA barriers between the development team and the team who takes care of the systems that customers use.

Situation Dependent (1)

jythie (914043) | about 2 years ago | (#41437491)

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.

For inhouse use: Dev - Test - Prod (0)

Anonymous Coward | about 2 years ago | (#41437501)

If code is being developed for in house use there should be three separate but identical systems:
Dev - development is done here - builds etc. with version control software used to track history and allow for roll back etc.
Test - once the developer has finished with the code - code is installed here for testing by QA - NOT by the developers, if critical bugs are found, back to Dev.
Prod - once full passed but QA, then and only then should code be install to production

Re:For inhouse use: Dev - Test - Prod (1)

dstyle5 (702493) | about 2 years ago | (#41438163)

Mod AC up! ;) I've worked in all three worlds and agree completely. Unless the developers are also the IT guys, they shouldn't be installing it.

Possible issues with letting Devs do this (3, Insightful)

Zontar_Thing_From_Ve (949321) | about 2 years ago | (#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.

Just so it's one or the other. (1)

CubicleZombie (2590497) | about 2 years ago | (#41437507)

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.

Automate the s**t out of deployments (0)

Anonymous Coward | about 2 years ago | (#41437529)

When done right, deployments shouldn't be a big deal. If deployment is a fully automated, no-brainer, one-click operation, it also shouldn't matter (much)who deploys. But prior to deployment to a live environment, make sure the package deploys correctly both to a clean test environment and a backup-from-live test environment. If you haven't already, set up nightly builds to do this.

Deploy teams need to understand the APP (0)

Anonymous Coward | about 2 years ago | (#41437537)

I do all our production deploys for a Big 3 dealer application. We do it this way so that I understand the app and can better trouble shoot it at 3am if It takes a dump. Because we all know getting a hold of the dev team at 3am is a crap shoot at best.

Yes,but not into production (5, Insightful)

Todd Knarr (15451) | about 2 years ago | (#41437571)

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:Yes,but not into production (1)

ImprovOmega (744717) | about 2 years ago | (#41437849)

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 (though they do still happen). Errors in QA are significantly reduced, and errors in Dev (very common) are easy to erase and start over again.

If you let devs install directly into production, there will be many, *many* errors that they miss and you better hope you have good backups.

Accountability (0)

Anonymous Coward | about 2 years ago | (#41437575)

I've been in a similar situation, where developers were actually stopping a production service, checking code out onto the prod box, compiling it in place, and troubleshooting it for hours after that. Our service support team hated it, and it caused a lot of penalties with our clients (which, of course upset the CFO and the investors). We went to a model where the dev team would give us a package, we would get it running on a parallel server, test it to make sure it was working, then swap the old and servers' addresses.

If the package didn't work, there was no negotiation- we just didn't deploy the new code and the dev team went back to work the kinks out. A side benefit was that the prod support team didn't catch hell for an outage; the dev team absorbed the full impact of their lack of attention to detail and quality. Things got dramatically better with the products after that.

It ended up making everyone's life easier. The whole dev team didn't have to be awake all night for the change, the time to make the change shrank from 7 hours to about 30 minutes, and the customers started seeing what was good about our product rather than the monthly multi-hour outages.

Dev and manager here (0)

Anonymous Coward | about 2 years ago | (#41437577)

I'm a developer and a manager at a small company and I can unequivocally say "no" here.

Developers installing software inevitably causes issues - even when you're talking about QA/Test. It invites short cuts and quick fixes that never get documented so six months down the line, no one remembers what was done or how to reproduce it. That's if the original dev is even still around, which they often aren't.

If deployments aren't easily reproducible by another party than you can't guarantee what's running or when it was running. This invites all kinds of issues - especially if you deal with monetary transactions. There's a reason why stuff like PCI requires separation of roles.

Note that I haven't even touched on the potential damage that can be caused if there is malicious intent.

Of course! (2)

blirp (147278) | about 2 years ago | (#41437579)

But only the two or three times to perfect the automated procedure.

M.

It depends on who carries the pager (0)

Anonymous Coward | about 2 years ago | (#41437585)

If the developer is going to get woken up in a mad panic to get customers back on-line nights and weekends, then, yes, she should be able to install software into production. And in this scenario the developer _is_ also the operations person. These scenarios usually don't last long.

I'm a DevOps person. I value developers getting close to production to better understand how customers are being impacted by their software, but I do not want them in a position to break things. My job is to keep customers up and happy and to never know I exist.

Good operations people are conservative (not as in being a Republican, of course) and only change production in a safe way. If the organization is healthy and prioritizes what's important, then changes can be made rapidly and often, but this doesn't mean developers get to do what ever they want.

No, no and for the third time no. (1)

jimicus (737525) | about 2 years ago | (#41437605)

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 has been carried out successfully in on a test environment - which is again separate to the developers' environment and is meant to mimic the live environment as closely as possible. ("Successfully" in this case means it installs cleanly and the updated version passes an agreed set of tests, including user acceptance tests). Ideally you'd have a separate test team who vouch for the build.

Yes it's slow and cumbersome. But it's not intended to be quick, it's intended to ensure that the IT department is not at home to Mr. Cock Up.

Heck No. IT/End User feedback loop critical (1)

crimoid (27373) | about 2 years ago | (#41437627)

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 is that the appropriate feedback loops into development must be established, implemented, and acted upon. Bug reporting, issue tracking, customer feedback, and the like are critical bits of information that cannot be ignored by development.

Are you kidding? (1)

kumanopuusan (698669) | about 2 years ago | (#41437641)

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.

Package management and auditing (0)

Anonymous Coward | about 2 years ago | (#41437643)

Enterprise systems come with package management systems. Use them. Developers should be required to develop in one environment, package it and test in a testing environment, then scheduled installations into production with some means of management approval and auditing. Any backouts required involve simply removing the bad package and installing the previous working one. But I speak from a sys admin perspective.

Not the dev's job (0)

Anonymous Coward | about 2 years ago | (#41437665)

- It's the build manager's job
  - It's the deployment manager's job.

Really -- this question completely depends on the size of the shop.

I've had sysadmins tell me that a platform that only ever runs on linux, they'd rather we didn't require a single cron entry to run -- even if that would require importing half a dozen new libraries.

And I think that's a potentially reasonable request to make... depending on /why/ they make it.

Unfortunately, in this case it was "I don't want to have to maintain the program when installing it". Tough shit, princess -- the time that job runs is important, and the manual and ticket system says why.

If you're building up to an MSI, you should have a person in charge of it depending on the build. Same with RPM or .deb.

For the past few years my builds have consisted of python egg files, and the sysadmin deploys it with two lines of config I supply.

Making devs screw with the install depends on... whether or not the dev's are responsible for the *whole* install. If they aren't, then no, don't have them use the instructions, you'll just interfere with testing.

Really, you're talking to the wrong group about it. When my install instructions for the magic-black-box ommitted that we use apache tomcat and two warfiles in it and I got an earful from a project manager, I gave it right back to her. Not my fault I consider them external libraries that speed things up. The system works just fine on a brand new install without them. They were previously installed on the platform, listed as "highly recommended dependencies" and our config file had comments on how to point to them with appropriate defaults for a default install.

But if you convert or upgrade the server and roll an existing install into the new one -- while following install instructions that helpfully detect an upgrade instead-- then yes, our install depends on the old services being on the new setup. And yes, we give a 'cryptic' error message .

Not my fault your sysadmin -- (the PM) is an idiot.

Yes, I can write a test for any given error -- but that tends to cause bloated, unmaintainable heavy code. At a certain point, it's time to assume competence. That means if you get a message saying I can't find tomcat, you man up and demonstrate that your degree made you at least as literate as someone with a decent background in liberal arts, much less the 20 years of experience you show on the resume.

Shouldn't really matter (1)

jvkjvk (102057) | about 2 years ago | (#41437681)

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 able to install on their test systems, as checking the install is part of the test process.

Once a gold build is produced, the people administering the production application servers or ESBs should probably manage the package deployment.

Please don't tell me the developers are also administering the production boxes!

But really, test is familiar, development is familiar, systems should even be familiar... It could really be any of them.

"Should" then just becomes a choice made, and someone puts it down on their time card.

Someone has to install it (1)

nedlohs (1335013) | about 2 years ago | (#41437683)

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

flink (18449) | about 2 years ago | (#41437699)

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 pool in Bangalore who doesn't know how the application works. They usually can't tell a software bug in our code, from a missed firewall configuration step, from bad permissions in the filesystem, from a bad load balancer config... the list goes on. That's when I get pulled in. Of course I don't have permissions to do any useful diagnosis, and they are so fresh out of training they don't know how to execute a TCP dump. ...and that's why I don't do J2EE development anymore :)

Big Ole Compliance Red Flag (1)

Anonymous Coward | about 2 years ago | (#41437705)

The folks above have commented on why it's a best practice for coders NOT to push their own code to PROD. Peer review, undocumented fixes, hacks, security holes, malicious insiders, it's all covered up there.

Which is why SOX auditors, PCI auditors, HIPAA....etc all look for separation of duties. It's a case where Compliance actually has Security's interest in mind.

Dev should not every touch the prod environment (1)

TomTraynor (82129) | about 2 years ago | (#41437729)

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 development team writes the installation document that defines every change required to release to production (and must match the modules in the specs) and the computer operations team follows that list of instructions. The list is also then checked against the change list and only the changes identified get released, anything else will not be released unless authorized by the support team and the client.

There are exceptions for emergencies, but, all code releases for any reason has to be signed off by the support team and client before it even hits the production machine.

The upside of this is that every change made has been documented and verified. All code released to the production machine has been documented and an audit trail is available for review. This way a developer will have a very tough time trying to sneak in code that should not be in a production machine (it still can happen, but, it is very hard).

Yes, when they do, they produce good software (1)

140Mandak262Jamuna (970587) | about 2 years ago | (#41437761)

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 since 1992. Why? Because we had tough time telling which project name corresponds to which project/design we had to test.

We wrote a pseudo "non rendering" window whose only job is to accept and dispatch mouse clicks, in 1993. We had an env switch to dump out mouse clicks during the normal run and then we use this non-graphical-non-rendering window mode to run jobs in a batch. That pseudo event dispatch window eventually grew into our record and playback feature. Then it grew into our macro play back feature. Eventually it grew into our "Command Langugage".

We wrote our own "process manager" to run the jobs in queue, run queues in different machines (only in unix, we used rsh).

We grew big, and we have a separate QA dept. They have bought expensive mouse-click-recording and playback software. They have an expensive bought some queue manager, remote job manager etc etc. But when we were doing our own QA, we felt the pain of the customer and added tons and tons of things to make our jobs simpler, and the customer benefited.

So, yes, eating your own dog food helps.

it depends (1)

a2wflc (705508) | about 2 years ago | (#41437781)

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 an approved provider.

In some cases, a seemingly simple new facebook page needs LOTS of input from LOTS of groups, and needs to follow a pretty complex process of who does what. In other cases, it's a trivial task that can be done in a morning with emails between 3 people.

The key is to think up front about the different classifications. What are the legal/privacy/security/pr risks? In our case, risks not just for the brand, but all brands in the company. What can/can't be done in the different classifications? What processes need to be followed for each? What common components/services can be used/deployed without a security or privacy risk? After that, each site can be managed with the quickest and cheapest process? We would have 1/2 the sites and 1/4 of the facebook presence if every site had to follow the same processes (or we'd have lots of privacy, security, and operations issues).

  While credit card sites are operated differently, all sites and facebook pages are operated by the same 2 vendors with the same SLAs. We worked very closely with the operations companies to come up with the different deployment processes so that we can have both the quick/cheap and more complex types of sites with the same 24x7 SLAs. We also worked with our legal, privacy, security, and PR teams to make sure they are all satisfied that the processes are acceptable.

automation (1)

itmo (605864) | about 2 years ago | (#41437793)

The best way to do this is to have automation. That serves as atleast some kind of documentation, it makes stuff repeatable , it makes stuff easier to replicate etc. Preferred method would be to have the automation in version control and a build machine which checks if a tag changes, then pulls the automation, executes it, it will install whatever is tagged, tag it as installed and shut down. Preferably this system is built so that you can only "please install this" tag stuff that is properly staged and autotested.

End users should be able to install the software (1)

markdj (691222) | about 2 years ago | (#41437821)

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 instructions for how to install the software. The industrial automation software I use can kill, cause fires, and do all manner of damage if not installed and configured properly. It is just good practice to have explicit detailed installation instructions, that someone with a modicum of knowledge of the system can follow to reinstall from scratch. I've seen plenty of customers who are using software for which they have no idea how it is configured or installed. The original engineers are no longer available. They were laid off in cost savings events. Then I have to come in to figure out what they have so that I can determine how to upgrade them to the latest version while preserving years of data because once the hardware failed you can't get it to use the old software and the old software won't run on newer hardware.

Developer Access Metric & Nomenclature (0)

Anonymous Coward | about 2 years ago | (#41437877)

Application quality/reliability is inversely proportional to developer access. 'Nuff said...

Only if the IT guys.. (0)

Anonymous Coward | about 2 years ago | (#41437881)

.. stop asking us to wipe their asses, and do it themselves.

Seriously? What kind of technical people are you hiring that can't take care of this?

Been there done that. (0)

Anonymous Coward | about 2 years ago | (#41437921)

I agree 100% with no. One of my clients bought a payroll system without asking anyone in IT to look at it. The developer required that they install it themselves. There were warring signs all over that anyone from IT would have seen a mile away. The developer install requirement was just the first clue. My thoughts are that if a company has not had time to build a decent install package yet, the rest of the product will also suffer from lack of refinement. In this case I was correct, and after less than three years we migrated to a different payroll product. I am continually surprised about how ignorant developers are about the operating systems they develop for. .. ESPECIALLY SECURITY! If politics prevail watch them like a hawk and do not grant them unsupervised access to you network.

Here is another issue to think about. We also had problems when we need to do any type of infrastructure work. We will work after business hours to complete a project as to not disrupt business operations. Will the developer do the same? Probably not. We had a great deal of trouble coordinating support from the developer to schedule work on the payroll system. After it was installed and the check was signed they kind of wash their hands of supporting anything other than trivial end user issues. It took 2 months to get them to coordinate configuring their system even for an IP change. Any problems they wanted to blame on IT; luckily we gave them a dedicated server so that excuse did not fly.

I would suggest that some products are very complicated and may require developer support to install and configure correctly; especially for some lame IT departments that I have seen. But if they cannot even write an installation procedure for their product, the install issue will probably not be the only issue you’re going to have with this product.

without a doubt (1)

heracross (2706015) | about 2 years ago | (#41437975)

I work in a company where the Datacenter , not developers deploys to test and production and they get it wrong a high % of the time. So yes. The datacenter employees don't even understand the server software or database involved , yet they control deployments. Its a nightmare

How big an enterprise? (1)

Tastecicles (1153671) | about 2 years ago | (#41438015)

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 the people to trust with such deployments, who can then carry out diagnostics when something goes wrong. In this case documentation and audits are important.

As a former SQL developer, in a very small company, I had complete access to everything. For me, it made life easier but more complicated, to be paradoxical. Something goes wrong, I have to stop developing and fix it myself. Therefore I'm incentivised to get it right first time, which means careful coding and careful testbedding and careful debugging before the product even sees the production machines. Then I can move on to the next job safe in the knowledge that the chances of me getting a call at 3am because of some bit of rogue syntax brought a few thousand £ worth of gear to its knees is next to zero.

closure: if the developer is coding for production where he is not likely to be called upon to drop everything and fix a problem on a production box, such task reserved for someone else, then full documentation of every call and function is an absolute must.

tsk (2)

Tom (822) | about 2 years ago | (#41438027)

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.

Hello? Installer = Package manager = instuctions! (0)

Anonymous Coward | about 2 years ago | (#41438041)

And what do you think an installer is, other than *software*, written by developers, that contains instructions, written by developers, on how they would install the software!

Let alone something more sane, like ebuilds & co for package managers!

*facepalm*

human interaction (2)

phantomfive (622387) | about 2 years ago | (#41438055)

I'm not sure a human should be installing anything manually on production environments. Upgrades should be done automatically.

probably not (1)

roc97007 (608802) | about 2 years ago | (#41438073)

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. Were I have knowledge that this practice is followed, I decline to buy from that company. Proper versioning, keeping the stack aligned, assuring a pristine QA environment, are all specialized skills that developers are not required to have, any more than race car drivers are required to be mechanics. (There. A car analogy.) Some may be, and a few may be good at it, but it is not their speciality and should not be a job requirement. (That said, developers should be on call for install problems that require dipping into the code, or may result in code changes.)

But again, it depends on the size of the operation. If you're developing a product with the laptop balanced on the ironing board, you do what you have to. But it becomes a lot more difficult to convince people that your product is enterprise ready.

Headline question? Answer is no. (1)

Imagix (695350) | about 2 years ago | (#41438119)

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 bunch of missing documentation.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?