I hate setting up my dev environment.

twitter logo github logo ・1 min read

Do you guys have complicated dev environments? I kind of do with all my terminal and text editor configs. I kind of want to simplify it all a ton but I love tricking out my terminal and what not. I just hate starting from scratch and setting up all the initial stuff. What do you all do?

twitter logo DISCUSS (23)
markdown guide
 

This is why I keep my dotfiles (.zshrc, etc.) in a private GIT repository. With this I'm to fullspeed in no time.

The same for "to-be-installed" packages. I save all my manually installed packages in a textfile, I can pipe into pacman (the archlinux package manager) to install everything I need :).

All this takes only a few minutes of maintenance per month, but gives hours on hours back a year :)

 

Why private? I think it looks great when I'm digging through a candidates repo and I get a look at his/her dotfiles. You can learn a lot about a person by their dotfiles. I do have a secrets repo that I keep private which my dotfiles reference.

 

I would say there are two keywords to solve this problem:

  • Sourcecontrol (e.g. github, bitbucket, $younameit) where you host configuration files

  • Ansible to get setups going.

Result: Reproducible dev environments.

Done.

 

I'd add Vagrant to that list. Funnily enough, I've just started trying to set up a repeatable dev environment using Vagrant + Ansible + Git. You can see my meagre attempts here:

github.com/stuartpullinger/devenv

 

Inertia! :) We don't have Docker as a deployment target at work so I've never been forced to learn it! Plus, some complication using Docker and VirtualBox at the same time on Windows 10 put me off. But you can use it behind Vagrant.

 

I have maybe a different perspective. I try to pick tools that I can mostly use as-is. There is always a little configuration, but if it gets to be a lot, I look for a different tool. Or maybe a similar end result can be achieved by using fiddly tools that can import/export their configuration easily and consistently.

Personally, I value high degrees of flexibility in the code itself, not as much in tools around the code. It seems funny to me when people want highly customizable/disparate coding tools but then use a framework in their code to avoid having to make choices about the real crux of their work. I prefer the framework approach for code tooling (by that, I mean something like an IDE vs text editors + a dozen plugins, each with their own configs) and the library approach for code.

And even with code tools, I try to use them as lightly as possible. Because they will change. A heavy investment in learning these tools will not likely reap a long term reward.

 

I created a github repo with all the tools and things I use to setup my development environments. So when I setup a new pc, I just go to the doc and copy and paste my environment back into life.

github.com/joelnet/development-env...

I'd love to be able to just script the whole thing.

 

Slightly different tack for me...

Given my main dev environment is Visual Studio (full fat version), and that typically takes several hours to install, I've recently been experimenting with the pre-installed developer VMs in Azure: 10mins tops to create, log in, connect to VSTSHHHHAzure DevOps, pull and go.

If I mess it up, I don't have to untangle anything, it's only had one job so I can burn it and build another. Cattle not pets even for dev work :)

I can work from any terminal with an RDP client, I can leave long jobs running while I travel, of course I don't get to access it without a 'net connection, but that's pretty unusual, even on trains.

 

Maybe Nix or even NixOs is a solution for you?
Can't speak from personal experience (I change my setup more often than I copy it), but I've heard good things.

 

I can speak from personal experience - its my current daily driver. The only downside is that now I'm scared to manage my configs any other way, which is silly. Nix really does take a lot of pain out of this. My desktop and laptop can stay completely in sync, environment-wise, and I only need to maintain a single config which covers the whole system. Should I decide to wipe and re-install, it's a one-click operation.

 

Tmux automation. That changed my life.
Since i am doing my development in Vim (terminal text editor), and my task runner (gulp) is a nodejs terminal command, and git command line is, of course, in a terminal, I would always run Three tmux windows when I am doing my work. And I had to do it every time I want to continue working on a project.
So what I did was to write a Tmux script that would automate all of that for me, including renaming of windows to normal human names like editor and gulp, instead of sh and node. I just enter a directory I want to work on, that I have been working on before, and run gulp-dev and it runs everything for me and in the end I am in the Vim window hacking away, in 3 seconds or less.

About STARTING a dev environment as if

  • setting up gulp tasks
  • gitignore
  • package.json

well I am just copying them from my previous projects, edit my package.json with simple npm init

and immediately my setup becomes the same as it was on the previous project. Unless I have to do a complete remodel, where still, my package.json npm run start command can be changed, but its running by my gulp-dev script anyways. I never touch the tmux script, its always the same, while my project can change.

You can see my scripts on my github in a dotfiles repository if you want.

 

Some tips:

  • Roll over your configuration from one machine to another when you need to build out your development environment. If you use something like Apple's Time Machine this is super easy, you just restore from backup and you're up to speed on your new machine almost instantly.
  • Use note-taking tools like Evernote, Notion or even GitHub Gist to save useful snippets. These can be a hassle to organize and tag, mind you.
  • Write down or record what you did when setting up your environment so you can do it again later without forgetting a bunch of steps.

If you want to formalize this more, think about making a git repository and "installer" for your various configs. You can easily do this with a bit of Python, Ruby or Node.js and a "serverless" place to securely save your content like Dropbox or Amazon S3.

 

I've published a piece on this matter. TL;DR is that dev environments should be described in code and continuously for every task be recreated from that.

dev.to/svenefftinge/continuous-dev...

 

I love setting up a new environment, doing it on a semi regular basis forces me to keep things clean. I got a new MacBook Pro for work recently, from opening the box to being back up at close to 100% productivity was < 1 hour with no backup restored.

 

I use a Chef cookbook to configure my dotfiles, install necessary software and binaries, and do some other custom things. It even has recipes for different environment setups I may need (Python, Go, Ruby) and the tools I use with each.

 

I find it's a problem because it's done so infrequently that it feels like you're doing it for the first time each time. I've taken notes for my latest dev setup but I expect things will have changed the next time I have to do it and my notes will be worthless.

I tend to go for a minimalist setup for avoid issues. I've seen other developers describe their setup and I can't help but think "do you really need all this stuff?". I set up pycharm, virtual envs, homebrew and am building up a .bash_profile with what i want in it, that's all. A fair chunk of it is automated and kept as a script in a private repo of mine and hopefully it's a single command to set up most of it.

 

I don't per se dislike setting up my dev environment, but it definitely has a lot of fiddly bits. I really liked notwaldorf's .not-quite-dotfiles set of setup scripts for her environment, and it was pretty easy to reverse-engineer to my own preferred setup.

 
 

I generally agree with what's been posted below already:

  1. Write shell scripts to install programs and config files to configure them
  2. Version control with GitHub or something
  3. ???
  4. Profit
 

I had the same issue yesterday, when I had to reinstall Ubuntu on it at the end, I just had to create a simple script that will automatically install my packages and setup everything.

You are welcome to check it out and contribute.

github.com/mmphego/xubuntu-pkg-ins...

It's also a good idea to backup your configs, such as bashrc, vscode/sublime text settings and etc

a simple way of doing it would be:

$ cd ~
$ git init
$ touch .gitignore
$ echo "*" > .gitignore
$ git add -f .bashrc .ssh

Add anything you would like to back up, personally, I like backing up my bashrc, ssh configs and settings, VSCode and sublime text settings and ...

You are welcome to check out my Linux-conf (flag it if there's any secrets I should have in public):
github.com/mmphego/linux-config

 

Having a repository from which to pull files — be it git, an S3 bucket or "whatever" — and an automation framework (Vagrant, cloud-init/cfn-init or their equivalents) means never having to worry about having a suitably customized environment.

...Well, if you're not using workspace that's controlled by corporate policy-nazis, at least.

That said, getting overly-reliant on a tricked-out environments can be paaaaaainful if you ever pursue consulting and become a frequent "guest" user. Even absent having to cope with corporate policy-nazis, you simply may not have sufficient access to do a quick, programmatic customization. That's ultimately what broke me of that habit. I'm now mostly a "least common denominator" kind of guy when it comes to environment setups. :(

 
Classic DEV Post from May 28 '18

Getting Stuff Done when Every Voice Matters

Resolving Developer Conflicts

Levi ᕙ(⇀‸↼‶)ᕗ profile image
I help people teach themselves JavaScript @thinkful & @trybloc. Working on my courses. I’m nice at ping pong 🏓