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?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (23)
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
Why not docker?
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.
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
editorandgulp, instead ofshandnode. I just enter a directory I want to work on, that I have been working on before, and rungulp-devand 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
well I am just copying them from my previous projects, edit my package.json with simple
npm initand 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 startcommand can be changed, but its running by mygulp-devscript 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:
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.
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.
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.
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.
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.
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 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 generally agree with what's been posted below already:
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 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 love this lol
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. :(