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.