Ask HN: Big software teams, how do you manage your computers? | Hacker News Reader

Ask HN: Big software teams, how do you manage your computers?

18 pointssekasi17 comments

I'm curious how big (this definition: Above 50) development houses manage licenses, installation of updates, software in general.

I've seen so many models in terms of locked down deployment, self-managed machines and I'm genuinely curious about what large software teams around the world are doing to keep themselves.. you know, legal, efficient and malware-free.

Thanks for any responses.

View on HN

I think most developers would quit if not given sudo access to their machines. Don't use windows and fire people who manage to install malware. Most companies use some sort of remote management app no one except IT cares about. Yes, it probably spies on employees. Software that needs licensed probably has a license server option.

Firing people who accidentally install malware seems like a tremendous waste of what a human has to offer a company. Can you really afford to lose someone over something like that?

If there is a pattern, yes. Nothing I do comes remotely close to accidentally installing malware. If they install malware it is probably because they are using their work-owned computer as their personal computer. If they are doing that they are doing something not very smart and they are probably making many other workplace mistakes.

On the contrary, I work at BigCorp where every machine is locked down - no administrator access, no sudo, etc. People routinely install programs to C:\ simply because it is writable. If you need admin access to install it? Forget it, open an IT ticket.

I've never heard of anyone quitting because of this issue.

Yes. BigCorp have very limited access to resources depending on their role. IF you need to install software OR require admin rights your ticket have to pass long tail of approvals with lots of justification.

Most dev shops nowadays use Vagrant to manage and provision their dev environments, making sure that all developers are on the exact same setup.

What part of git + commit-based CI/CD processes doesn't scale?

Git isn't going to manage the licences for commercial software and your operating system updates ...

This. I think people were too quick to judge the OP as an idiot. He's not talking about your applications. He's talking about physical developer hardware. The laptop sitting in front of you.

Nobody called the OP an idiot.

The consensus is that physical developer hardware is best managed by developers.

The 'problem' of managing 'large numbers' of 'commercial software licenses' is not a problem with automation; unfortunately it goes against the grain of developers managing their own hardware.

It seems the real problem in the OP's organization is management unwilling to delegate and constantly searching for centralized solutions to trivial 'problems'.

So what you're saying is each machine would be a build slave? Interesting idea.

Nope.

Normally in a centralized system you would hook up CI/CD processes to dedicated infrastructure, so that when developers commit to your RCS/VCS server (github, gitlab, whatever else), builds and tests are automatically run.

This infrastructure may be a dedicated system, a cluster, or outsourced infrastructure (real or virtual).

Because git (or any other RCS/VCS) is a well defined formal interface between the developer and the rest of the development-related business processes (automated or otherwise), it means individual machines can just be user managed, which developers tend to prefer.

It's worth mentioning that there is a school of thought that builds or tests that take longer than a few seconds on a developer's machine are undesirable from a workflow optimization perspective and may be indicative of a non continuous delivery (CD) capable codebase, with probable features such as knowledge silos ("only that guy knows"), undeployability, low quality, lack of project visibility, infrastructure tie-in and late defect discovery.

While a few seconds is unrealistically fast, if you ask me, I did notice that long testings duration is very detrimental to the quality and testability of a code base.

If you have to wait 1h for testing feedback it kills the development inertia.

And so do slow development tools, compiling something for 2 h and then getting negative feedback is not cool, and yet this is something I've seen happen at my current job and it drives me insane.

compiling something for 2 h and then getting negative feedback is not cool, and yet this is something I've seen happen at my current job and it drives me insane.

You could consider an on-demand cloud-based compile farm, or incremental builds with snapshots.

I worked on a large deployment (hundreds of Macs) that used custom scripts to harvest, and backup license files. Our scripts were executed with Apple remote desktop and also used JAMF.

At the time other companies (such as google) used puppet + custom scripts to deploy their license files + other executables on their Macs whilst leaving the users with sudo access.

Typically I've seen teams have a set of build-machines that use NIS/LDAP to authenticate and authorize users, but also auto-mounts an NFS home-share on something like a NetApp filer when a user logins. Developers have their own laptops and ssh/XForward to build machines.

At the various banks I have worked at, PCs are all windows and locked down. You can apply for Admin access (or a more limited version via a 3rd party product like Privilege Guard) if you a developer.

Reply on news.ycombinator.com