I have finished enough of a ground-up rebuild of a developer machine to take stock. The rebuild process went something like this:
Step 1 – Start long running installation
Step 2 – Wait for installation to complete
Step 3 – Go back to Step 1. Rinse and repeat …
Hard Learnt Lessons
- Building a Windows based developer workstation takes more TIME than you imagine
- Long periods of WAITING for installations to complete is WASTEFUL
- Rebuilding workstation machines is REPETITIVE
One more point on the the manual build process. I will never have to do it again!
What is the ‘Catch of the Day’ then?
With a little help from Chocolatey and Docker a machine configuration is quick to define and can work with any Revision Control tool. In return for time invested you get to manage complete machine configurations via little more than a handful of scripts and GitHub Gists.
As you will see I like to run on a developer machine with a fairly spartan feel to it. Hence my secondary goal, keep application runtime dependencies off the machine if at all possible. Today these applications can often run very efficiently hosted inside a container.
If you have already nailed this way of working I would advise moving on quickly, there is little more than the basics in this post.
Install base Windows 10 Pro or Ent edition of Windows onto your development machine.
Chocolatey is a package manager for Windows, providing automation around managing software applications.
Open an administrative command prompt and enter the following:
C:\> @powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
That’s it, we now have all that we need to start installing our own GoTo Developer Toolset
Start Installing Applications
What you install on your developer machine is really up to you. To get a better idea of the range of application packages available take a look at the fully searchable Chocolatey Package Gallery.
For ease of maintenance I keep my developer machine configuration as a GitHub Gist.
Little tip: disable the prompting actions for confirmation in scripts or bypass issue the following command in an administrative command prompt before installing all of your packages.
C:\> choco feature enable -n=allowGlobalConfirmation
Then simply start installing the packages that you want on your local machine.
C:\> choco install The-Package-Name
Viewing Installed Packages
You can list all of the chocolatey packages installed on a local machine by typing:
C:\> choco list -lo
Add a -v verbose parameter to the command to get detailed information on locally installed packages.
C:\> choco list -lo -v
Configure your GIT environment interactively by diving right in and editing the global configuration file for the current user with the following command:
C:\> git config -e --global
Setting a Custom Visual Diff and Merge Tool
It is a personal thing, but for me I cannot seem to get along with the 3-way diff and merge tool that comes with GIT out of the box.
My preference for a 3-way diff tool is P4Merge. It is Free and at the same time has all of the Features that you generally need from such a tool. For this reason the configuration examples shown below are specifically for P4Merge. Selecting another 3-way diff tool would follow a similar configuration process.
Open an administrative command prompt and update the user’s global GIT configuration.
C:\> git config --global merge.tool p4merge C:\> git config --global mergetool.p4merge.path "C:/Program Files/Perforce/p4merge.exe" C:\> git config --global mergetool.p4mergetool.trustExitCode false C:\> git config --global mergetool.keepBackup false C:\> git config --global diff.tool p4merge C:\> git config --global difftool.p4merge.cmd "C:/Program Files/Perforce/p4merge.exe \$LOCAL \$REMOTE"
Information for the advice given here originated from the following posts:
Docker is a big player in the software containerisation platform market.
Kitematic comes installed with Docker and offers a simple graphical user interface through which to install and manage containers.
The next post will delve a little deeper into how I keep application level dependencies off my machine wherever possible.
The first dependency to fall by the wayside may well by my existing Blogging framework. To that point, the Markdown source for this post is available as a public Gist.