In my experience:

1. There's very rarely a one-size-fits-all solution, in terms of what people need. Oh sure, if everyone needs a VPN then you should install the VPN and suchlike. If there's mandatory corporate security software, add that as well. But will they need docker? Will they need virtualbox? Will they need VS Code? CLion? PyCharm? IntelliJ? Do they need Java installed? Which version of Java? Will they need Altium? SolidWorks?

2. There's constant churn. You can't just create an image once and use it unchanged for years - there are so many components involved that there'll be some change or other needed pretty much monthly.

And you can't rely on volunteers helping out to scratch an itch - everyone in a position to do that has long since got their computer set up how they like it.

What's more, lot of the changes you end up pushing out will be unpopular. Ain't nobody going to volunteer their time to add a giant block of all-caps legalese to a login banner, or to deploy enterprise security crapware like crowdstrike.

3. Laptops are imaged by level 1 helpdesk workers. People who can troubleshoot Linux problems and maintain setup images probably aren't in helpdesk at all, and certainly aren't level 1.

So if you imagine making an image and handing it over to helpdesk to maintain - you'll find doing so isn't possible.

And then, in Windows, you likely want WSL, and you will likely need a mix of some tools in windows, some in linux and some in both. It can definitely get messy. That doesn't even count developer tool preferences.

I created a relatively long set of install instructions for Windows+WSL[1] a couple years ago and it's already outdated in a few areas. I mean most should be able to figure it out, but it just really varies a lot. Even with WinGet, Chocolatey, etc. Windows is just the odd duck here. Doubled with the Linux/WSL bits.

Linux is probably the easiest to script out, second would be mac imo, but need multiple steps with homebrew, etc.

1. https://github.com/tracker1/personal/blob/main/developer-set...

There should be an automated way to customize the setup using a series or checkboxes and/radio buttons options. Check VSCode, Git, Java version whatever, click Run, come back in an hour, and it is done. Helpdesk workers should not need to be involved.

like an enterprise version of ninite.com ?

In my experience, doing the automation is very easy but getting the list of requirements is very hard. The guys taking an entire day to set up a computer could just install their stuff with (any package manager), so why does it take so long? They don't know what they need and just go with it until they hit a road block.

We pre install the licensed corporate tools and universally used tools like np++ and git for windows, and let them figure out the rest. Every time we bring up baseline changes with that group it turns into bikeshed city.

I usually live in WSL2 on Windows running on company provided laptop. Each time the laptop has to be replaced (failure or age) I struggled to get my "home" back up so a couple of years ago I took a full day to setup my so-called "dot files repo".

My goal was to be able to install any debian-based distro and run a single script, non-interactive, that would get me up and running. All that I needed to do was to clone code I wanted to work on.

After I created the dot files repo the process was:

- install distro

- checkout dot files

- run script

- do I have everything I need? (minikube, k9s, jq, yq, asdf, terraform, git config, nvim config, etc.)

- if no, then:

   - fix, commit, push

   - remove distro

I have similar in a backup directory on my NAS. Works pretty well in general for getting my home directory up and good.

WSL, I usually have to make a few adjustments, mostly so that I can use the git credential manager installed in windows from Linux git.

Similar set up with a dotfile repo then I use GNU Stow to manage my dotfiles once I clone the repo.

I would take "Now some people ask for an automation to get a "pre-installed" laptop" as a lack of " developers preferences".

Personally I dislike Git, and haven't found a git UI I like, so throw whatever you want on there. I am not going to like it, but not because I want something else.

Since you support a range of OSes I assume you would go with a cross platform editor IntelliJ, VSCode or something. Both are fine, and "something" probably is too.

I like beyond compare enough that I bought a personal license for it.

Give them a 100% works out of the box then they can customize the 1 or 2 things they care about.

> Personally I dislike Git, and haven't found a git UI I like, so throw whatever you want on there. I am not going to like it, but not because I want something else.

I might be a bit off topic here, but if you haven't tried Lazygit yet, I can't recommend it enough.

Lazygit is fantastic. For a GUI I highly recommend sublime merge.

I like git okay... mostly use the CLI for it. I do use the VS Code integrations sometimes though. A big part of why I like VS Code is the integrated terminal though.

After corporate IT gives out a MacBook, we run a local-only Ansible script I wrote.

It sets .zshrc, .zshenv, and .zshenv-private for tokens etc.

It also uses Homebrew to install a bunch of packages, then creates various config files.

It works well. Developer setup time went from days to less than 2 hours (corporate VPN is slow)

Edited to add:

Workflow is:

  1. Install homebrew, xcode command line tools, Ansible, and then git+credential helper.
  2. Clone repo (which ensures the new dev has correct roles/groups to access the repo)
  3. Run Ansible.

Snippet of the Ansible script:

  ---
  - name: Configure dev macOS
    hosts: localhost
    vars_prompt:
      - name: githubtoken
        prompt: What is your github token?
        private: false

    tasks:
      - name: Create variable from brew prefix
        ansible.builtin.command: "brew --prefix"
        register: brew_prefix
        changed_when: false

      - name: Update Homebrew
        community.general.homebrew:
          update_homebrew: true

      - name: Install GNU Coreutils
        community.general.homebrew:
          name: coreutils
          state: present

I've never used Ansible. Is it worth using for just this workflow? I'm asking coming from a baseline of just having a Git-versioned shell script which has lines like

    brew install coreutils

and whathaveyou.

You get the nice stuff that Ansible brings, like adding specific lines to .zshrc, templates, etc. I found it easier than my usually-beloved shell scripts because I didn't need to think about the mechanism, just the result.

For example, brew install coreutils would use the community.general.homebrew module: https://docs.ansible.com/ansible/latest/collections/communit... <-- you can see from that page that each module has lots of examples, which makes it pretty easy to go from requirements to Ansible script.

You have to think about the mechanism if you remove a file. Ansible is imperative like a shell script, not declarative.

For Developers on Windows 11, depending on what you think of Microsoft's "Preview" status, the growing power tool here in this space is Windows Dev Home: https://learn.microsoft.com/en-us/windows/dev-home/

One of the key pieces of Dev Home is Machine Configuration via WinGet Configuration files [1], which are an upgrade from PowerShell DSC, if you've tried that for server configs, with increased support for installing software from WinGet, cloning git repositories (to Windows Dev Drive if you want to allow that). These config files are just YAML files so you could very easily offer starter templates and also allow developers to customize them based on their own preferences. (Also as YAML they could be source controlled in git themselves.)

Some sample configuration files: https://github.com/microsoft/devhome/tree/main/docs/sampleCo...

Microsoft has been iterating on Dev Home pretty rapidly and adds new features regularly (relatively recently it added support to applying the same configuration files to building new virtual machines either locally under Hyper-V or remotely with Microsoft Dev Box).

I've not yet seen a company try to use WinGet Configuration and Dev Home as a company-wide initiative, but I have seen some growing "bottom up" usage as Developers like myself adopt parts of it for our own multi-device needs or virally share YAML snippets among each other for common corporate repos and tools.

[1]: https://learn.microsoft.com/en-us/windows/package-manager/co...

For software developers, `asdf`[0] and dockerized projects goes a long way. For provisioning the environment variables needed for development, HashiCorp's `vault`[1] can make that pretty simple. Combine that with `direnv` to have it load the value dynamically with:

```

# .envrc

API_KEY=$(vault kv get -field=API_KEY secret/projectA/dev)

```

I also wanted to experiment using `pass`[2] instead, but messing with GPG keyrings and the like is unwieldy and not too user-friendly. It's what I use for personal projects since Vault is overkill.

[0] https://github.com/asdf-vm/asdf

[1] https://github.com/hashicorp/vault

[2] https://www.passwordstore.org/

I believe there is `pass-age` https://github.com/FiloSottile/passage ... unifies to `ssh` keys as the key material.

https://github.com/FiloSottile/age

``` RECIPIENT can be an age public key generated by age-keygen ("age1...") or an SSH public key ("ssh-ed25519 AAAA...", "ssh-rsa AAAA..."). ```

Buy an MDM, spend a couple of days setting it up and you’re off to the races.

Every place I’ve worked at where I had some control over workforce device management, we had devices shipping from the store directly to the end user, which would get automatically set up once the user logged in with their gsuite creds.

Your setup process is aligned with my industry experience (15+ years).

As for an installation script - I agree that is a big effort. ROI depends on frequency of the onboarding process. 10+ people per week? It might make sense. 3-4 people per year, not so much.

Smooth onboarding is a feature, not a baseline. Great onboarding takes consistent time, effort and energy to create and maintain.

Ensure that you have a predictable time to complete the onboarding. 1 day, 3 days, 2 weeks, etc. Time to complete onboarding should be very predictable and consistent.

Use relevant measures to reduce onboarding duration. Example: our developers need to install Oracle database on their Windows machine - normally it takes several hours to complete this step. We found that the Docker setup for Oracle can be completed in less than one hour.

i think a developer should be "in-tuned" with their tools, and time spent installing and configuring them is still "work"

they can automate the setup on their own if desired

also.. https://www.jetify.com/devbox for specific project tooling

Which tools are you specifically talking about? I'd argue there are chore installations that devs do repeatedly along with important personal items they should be focusing on to improve their workflow.

What you describe is great from the dev perspective when you have experienced devs with an interest in automation/tooling. From the company (or other dev in a larger organization) perspective, it can become a bugbear. Having some minimal dev environment that is accepted across the whole dev team is helpful for onboarding, or rebuilding machines when something seems off.

In most organizations, devs are rightly fearful of the pain that a rebuild will bring. That pain can and should be mitigated by the IT team with empathy for devs, scientists, or whatever audience the machines are for.

I wouldn't advocate for trying to achieve an ideal setup, but rather some baseline that isn't offensive e.g. if you put VS Code on there make it a checkbox option with other tools. Start with things that take a long time to download and install. Many of the personal tools and configurations are relatively small compared to the Visual Studio install on my current machine, or Xcode on my Mac.

Thanks for sharing Jetify. That's why I love these threads on HN.

What's missing is how many onboardings on the dev do you expect per year?

If it's like 10 or even 25, then it's not worth the extra automation. More than 50 is when the time is worth it.

What kind of software are developers building and do they have automation/CI for this? In my company we are mostly deploying web apps to Linux with devs using all of these laptops. If you have a wide range of development going on, then I'd suggest prioritizing the feasible ones.

Using https://github.com/bradwilson/ansible-dev-pc (public equivalent to ours), you can automate the setup of a Linux laptop or WSL2 environment under Windows. This covers a fair chunk of our dev team. Once you start thinking about making this work on macOS, it starts becoming quite a bit more work, but it's not terrible if management values the effort.

If you have people doing mobile and Windows desktop development in addition to Linux web apps, it starts to get much more complex. Maybe you can't offer a fully "pre-installed" laptop, but you can automate the time-consuming parts like a Visual Studio install.

From experience, you are going to encounter a lot of developers who struggle more than you expect with troubleshooting and automation of their work. This includes experienced devs. It seems to turn on interest and curiosity versus dev experience. It helps to create a checkpoint at onboarding where you make an effort to determine the best approach for them and know who accepts an automated happy path provided by you and who wants to handle things on their own (and perhaps fails). You can then report on the general pattern of issues to management and prioritize ways of improving your happy path build so they don't reject it.

IT here.

Devs need to manage their own. We hook it into AD/AAD, EDR and Office 365.

Dev enviroments THEY setup as THEY are developers. If then cant install some stuff can they even dev?

Setting up the environment for development, especially for onboarding, is a crucial operations step that allows the devs to stand on the shoulders of giants.

If you're asking them to test in prod ( not providing a local test environment for component testing ) or reinvent the wheel ( and get the wheel type right... should I build a bicycle wheel or a railcar wheel? ) then the first week of a new hire is spent trying to align to his or her peers.

Depends on the size/scale of the larger org and the developer team in question. There's a lot of variance even in internal corporate tool teams as to what gets used. Are you supporting an older .Net Winforms app, or are you supporting a React/next application or a Java Spring app? The tools you need and use will be very different.

Is it really worth trying to automate everything for a team of 3 devs on a given project? Should this just be done by the devs on the project if that's the desired outcome?

This is what I am getting at, thank you.

They have test environments. Where did you get "Test in prod" from?

But what they need to install depends so much on the project, and they all have pet machines. C# very different from C or something, right? :)

I only modify my system with Ansible, and when I am given a company laptop, I can have all my config, tools, etc. installed and configured right away with zero issues. Then most of the times, the dev env itself is based on docker and it's also done in a little time. So you could use something like ansible instead of docs

Here's how I would do it, very opinionatedly.

- Step 1. Use only Linux. You avoid having to translate between operating systems, you avoid paying expensive licenses, and you make your environments repeatable across dev machines. If a dev needs software that's only available on Windows or MacOS, have them run it in Docker or in a VM.

- Step 2. Define your software, programs, and user configuration in a .nix file. Create variables for user-specific stuff (usernames, email addresses, preferred software, etc.) and put them at the top of the file, so that you or the dev can easily edit it. Keep the Nix file in a Git repo, but allow your dev to maintain a separate branch. Build the Nix file into the system with `nixos-rebuild`.

- Step 3. There is no step 3.

Similar here.

More than onboarding, there is also the question of changing your laptop, and having to setup everything again.

Some pieces of software that help:

- Humble bundle (https://github.com/homebrew/homebrew-bundle) with a `Brewfile` stored in git and shared;

- dump of all dot files in $HOME encrypted and stored in the company's cloud (because it contains ssh private keys, or password manager db, etc);

- All documents are synchronized with OneDrive.

Mostly, there isn't a one-size fits all, but there is a common set of packages that all devs want, but IDE choice is personal, and many other things.

We use a mix of winget and chocolatey for everything via a python script. We also check the tool version when we configure our project with CMake. Sadly, we had to implement the version check for each application.

Some teams are using https://chezmoi.io to set up and maintain their developer's machines. It runs on Linux, macOS, and Windows.

https://install.doctor/ is a higher level option which uses chezmoi.

I'm really out of the loop on this, but in the past for Windows at least you could customize an image and use PXE to install it from the network. Then all the user had to do was login with a domain account.

Does that not work any more or is it just not popular ? Any insights as to why not ?

At least in the Apple world, my IT dept drop-ships MacBooks direct from Apple to employees, already enrolled in our MDM via their business partner program. Any additional software installations and provisioning happens after first boot via the MDM platform.

New hardware is never on a company campus or in IT hands where it could be pointed to a PXE server and imaged in that way (assuming we were running a Windows fleet too)

Direnv plus nix will go a long way on linux and macos. Windows should be using wsl anyway.

If you can get an image with just those two tools installed then each repo can specify what things it needs and when you cd into the repo it will install all the tools you need.

We have a mixture of MacOS (managed via Jamf Pro) and Windows managed via Intune/Autopilot.

All of us are AD integrated. Some software is managed (auto updated/installed) other software is up to us to manage.

Both setups work pretty well.

Can everything live inside a docker thing that you redistribute?

Distribute a container and a link to Podman Desktop:

https://podman-desktop.io/downloads

Isn't that only for big companies?

From https://www.docker.com/pricing/:

> Commercial use of Docker Desktop at a company of more than 250 employees OR more than $10 million in annual revenue requires a paid subscription (Pro, Team, or Business)

To be fair, if you have fewer than 250 employees and are going to stay that way for very long then you have no business worrying about automating onboarding scripts. It will take too much of your time for too little gain.

Unless you are getting ready to hire a lot of developers, or churn a lot of developers, the three OS choices mean 3 versions of the same image/script to get setup. That now becomes another application you have to manage. The setup docs are more of a live training not a waste of time. Their setup time will never be zero as they have to setup logins, verify license keys, etc, for all the tools that are installed.

The internal IT team should already have a way to configure security software and such but will also not want to manage a specific group setup for likely a small amount of people.

Reference.

https://xkcd.com/974/

What definitely doesn't work is one-size-fits-all. It doesn't work with hardware specs, it doesn't work with software, and it doesn't work with workflows. Managing Windows, macOS and Linux is all different enough to only get value out of it if you specialise a bit for each.

Here comes a somewhat long form answer that doesn't cover everything but covers enough, assuming you have a tech department (be it SWE, testers, platform etc) of at least 100 users.

For Windows: Use Intune and Company Portal, don't bind to AD, but use Azure as that is a requirement for native Windows lifecycle management.

For macOS: Use ABM and ADE with an MDM (like Jamf, Mosyle, Addigy, Kandji), they all come with the option to deploy a self-service portal. Don't bind to AD, don't log in with Azure, especially on single-user devices. It antithetical to lifecycle management of macOS, and doesn't help. Do escrow FV2 to MDM. Optionally you can enable DEP which enables you to do more smooth transitions for existing devices. Using MAIDs can help with resolving a user to a directory user but isn't a requirement.

For Linux: if someone wants Linux, they usually also have specific preferences for their productivity. Providing something in terms of "here, have a linux" is something I have not seen being very effective or efficient. I have had fleets where there was a default supported setup (Debian mostly, but some orgs defaulted to Ubuntu). There were two approaches:

1. Hands-off, you want Linux, you'll probably know what you're doing, just enroll into osquery so we know your posture.

2. Hands-on, you can pick our defaults or roll your own, but you'll get a SaltStack Minion configured and our Master will append your installed packages and amend your configuration as needed. Interaction is purely via chat for end-users (chatbot style in IRC or channel integration with Slack).

As for how this then works provisioning-wise:

Windows: you publish packages to the Company Portal. They can be of many shapes and sizes but we've found that ensuring that everything is actually a package and not some wrapped script is the way to keep it clean and functional. We use pseudo apps that pull in dependencies to automatically install everything you need. So if you're maintaining some legacy .NET WPF app we'd give you VS, various .NET versions, WSL2 (so you can use normal Git and interact with our services), and perhaps Rancher Desktop if you need to mock some endpoints locally.

macOS: you publish packages to the self-service app of choice. Generally they are all Installer packages but it's fine if their payload is mostly scripts since it's mostly Unix under the hood anyway. We use groups of presets so someone can click "configure me as if I were building microservices with Go and NodeJS". This would result in Rosetta, XCode, Homebrew, JetBrains, VSCode, UTM, Podman all being setup in the background and the user either getting a SwiftDialog about the process or just a notification after completion.

Linux: you publish formulas to Git and for hands-off people can read those, for hands-on you ask your chat system of choice to handle it for you. We use some jinja2 magic to pull in many formula configurations at once, and inside the formulas we try to support at least from-source, apt and dnf. But often we'll only have the automation for apt as that is where the majority of "I need Linux but I don't want to do it myself" lands (the default distro we deliver). We don't have zero-touch provisioning but instead ask users to log in on our enrolment portal and download a small Go binary that does the enrolment for them.

For all of them we keep the sources in Git so we don't end up needing a billion service desk employees writing arbitrary application profiles for multiple platforms. If someone wants to add support for their special flavour of the week, they can do that, and after a review it'll be available. That also includes OSQuery packs we use for cross-platform posture management. There is no need to hide this, and especially in a technology BU you will only create friction with opaque top-down management. They (we) will always win as technologists will find ways to do things that get the job done and hide them if needed.

This model is of course not the same as say, accounting users, or marketing or C-level. They get Chromebooks or a computer of their favourite brand that is essentially turned into an expensive web browser kiosk. The only legacy 'fat' managed systems that remain are offline systems that you might use to manage PLCs in the field. That's mostly older (but supported) windows versions that people don't want to ever reboot or shut down because the old school way of managing those means it takes almost 50% of the time of a job to boot and authenticate before you can start to get any work done. But that's often as required by some compliance or regulatory regime.