Current development environment

Based on what I have in my downloads ...

Content
FiraCode
Hasklig

Desktop Utilities
7z
BCUninstaller
Chrome
Ditto
Firefox
Sharp Keys
Spotify
Sumatra PDF
Google Drive Sync
Microsfot Office
Opera
Paint.net
MP3TAG
uTorrent

Dev Utilities
cmder
dnSpy https://github.com/0xd4d/dnSpy/releases
Expresso http://www.ultrapico.com/expresso.htm
Fiddler
FileZilla
Git
ILSpy
Docker
nuget
Postman
Saxon (HE,PE,EE)
SysInternals
WinMerge
Balsamiq Mockups
WebDeploy
Boxstarter
Rufus (Boot USB Utility)
Tortiose GIT

IDE & Editors
gvim
LINQPad
npp (NotePad++)
VSCode
XmlNotepad
notepad2
VS 2017

Languages
dotnet core 2.0
node 6
Anaconda# 4.3
clojure 1.8
jdk 8.1
python 3
ruby 2.3
.net 4.7

Servers
SQL Server 2016

Tool Sets
Font Awesome
Docker
RabbitMQ

Please Move to the Rear of the Bus

if we’re gonna do this thing, let’s do it better
A little house cleaning is in order, the RabbitMq server we set up last time was on a bare bones Windows Server. It is running on Hyper-V network on my Windows 10 dev machine. I’m going to add that new machine to the Hyper-V network, just to pretend this is enterprise level. I should have done this as part of the set up of the machine, this can be done with sconfig.cmd and then interactively perform the task but I’m all about the automation, and automation means script. So, the following will change the machine name, add it to a domain and enable a remote shell (this would be batchable into a deployment script):

netdom renamecomputer %COMPUTERNAME% /newname:monkey /force
netdom join %COMPUTERNAME% /domain:{your domain} /userd:{domain admin} /passwordd:{domain password}
WinRm quickconfig
shutdown /f /r /m \\monkey /t 0

At this point the service bus is on the network and we can access it from a commandline as needed:

winrs -r:monkey.floatingman.org -u:*******@floatingman.org -p:******** cmd

If you did all this this after setting up the service bus server (as I did) you will need to reconfigure RabbitMq to use the new server name. The simplest way to do this is to rerun the .\rabbitmq-server-3.6.1.exe installer again.

References to useful documentation:
netdom renamecomputer
netdom join
remote access to a core server

© 2016, Floatingman IT Consulting

A Trip on the ServiceBus

or installing RabbitMq on Windows 2012 r2 Server Core
Note: if you are planning to install this on a domain server have a look at this post first, otherwise you will need to reinstall RabbitMq to work correctly on your domain.

The destination of this voyage is to set up a RabbitMq Service Host on a Windows Serer with the use of the graphical interface.

At this point I have a clean installed Windows 2012 Server running on a local Hyper-V.

First, download and install erlang (Here’s what Microsoft has to say about downloading on the command ine with BitsTransfer.):

mkdir \downloads
cd \downloads
powershell
$url = "http://erlang.org/download/otp_win64_18.3.exe"
$output = ".\otp_win64_18.3.exe"
Import-Module BitsTransfer
Start-BitsTransfer -Source $url -Destination $output
.\otp_win64_18.3.exe

You can “next”, “next”, “install”, “close” over the dialog boxes (it may ask to install the VC redistributable).

Next download and install RabbitMq:

$url = "https://www.rabbitmq.com/releases/rabbitmq-server/v3.6.1/rabbitmq-server-3.6.1.exe"
$output = ".\rabbitmq-server-3.6.1.exe"
Import-Module BitsTransfer
Start-BitsTransfer -Source $url -Destination $output
.\rabbitmq-server-3.6.1.exe

Again, “next”, “install”, “next”, “finish” and you’re done.
Punch a hole in the firewall. Yeah I know, this next command just shuts the firewall off … we’ll set it back up shortly:

netsh advfirewall set allprofiles state off

Set rabbit up as a windows service:

exit
setx ERLANG_HOME "c:\program files\erl7.3" /m 
setx RABBITMQ_HOME "c:\program files\RabbitMQ Server\rabbitmq_server-3.6.1" /m
setx PATH "%path%;%RABBITMQ_HOME%\sbin" /m
rabbitmq-service install
rabbitmq-plugins enable rabbitmq_management
rabbitmqctl add_user admin admin
rabbitmqctl set_user_tags admin administrator
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"

It is at this point that you should be able to connect to the admin console via a web browser at:

http:\\{your-server-ip}:15672\

Disclaimer: This is not a properly configured production server, among other things (as noted earlier), the firewall was turned off and the admin|admin username|password is just silly. The rabbitmq web site covers the production settings in depth: read it.

© 2016, Floatingman IT Consulting

A DevOps Voyage - The Plan

Part One - The Plan

One the first voyage out we will be setting up a continuous delivery platform. The goal here is to explain how to setup a DevOps system for a small development shop, that builds web based applications. This is not a definition of DevOps, this can be found online; for example: DevOps on Wikipedia or why you should, or should not use DevOps.

I’m making a bunch of assumptions about the small project that is being deployed but the process should be dead easy.

while(!isFeatureComplete) {
    CheckCodeIntoSourceControl();
}

That’s all there should be too it from the contributor point of view. While this may initially look like an extreme simplification, it really isn’t; I’ve removed the write code portion because while it may be essential to the product, it is not essential to the process. The actual process of writing code is not included in the simple loop, it should not matter where the work artefacts come from, they could be copied from another project or new test data records.

This is the desired level of effort that should required to contribute to the product. Yes, this only discusses the actual coding activities and not the requires gathering or business analysis that goes on before hand. There are activities that are not covered by DevOps, these are two, let’s pull this out as important and perhaps we can circle back over it later.

Integrating product management into the continuous delivery processes.

All the other activities that we would expect to have in a development process are incorporated within the framework of the loop; this includes feature verification and deployment. Before we step into our simple loop we need to do some prep-work, we need to define what the system will look like for our activity.

The process

Let’s start by defining the process that we are attempting to automate:

1. source control repository
2. source code compiler (not required for non-compiled languages)
3. unit test runner
4. gated check-ins (passing unit tests)
5. automatic and gated deployments (passing integration tests)
6. continuous monitor

Next, we’ll define the environment. Whether these machines are physical or virtual is slightly immaterial, however, virtualization does give additional capability that physical machines do not. My assumption is that all machines (with the possible exception of the actual dev machine) are virtualized, at a minimum the deployment servers need to virtualized so they may be spun up and . So then, the following is a list of machines that will be used to build the process.

1. source control server
2. local ‘dev’ machine
3. build server
4. deployment platform(s*)

* It is completely possible that the deployment target server could be multiple servers, for example: application, DB, web, message, etc.. The actual number of servers is important only to the deployment script. Furthermore the number of actual deployment platforms will also vary, the likely number being two (test and production) though this can easily grow to include multiple levels of testing (UAT, Performance, Accessibility, Data Integrity, etc) and multiple production environments (by geography, early release/public beta, etc.). For the purposes of this voyage we will assume two deployment environments; testing and production.

All together the process of setting up a complete DevOps environment should not be more then a couple of days effort. Here’s the order we’ll take these things in:

1. setting up source control
   either local or remote, should also include a source controll client
2. setting up a build server
   once the source control is set up, getting things into and out of it
3. setting up a deployment server
   finally standing up a build in a test environment, also some discussion on virtualization

Within each section I’ll try to cover as much as possible from the both the why and the how.

Next up Part Two - Source Control

Out About the Harbour

I’ve been a software developer for twenty years, always mostly working for small or micro dev shops. This is my attempt to give back some of what I’ve learned, a least all the good things. The target audience of is the micro dev shop, with five or fewer people touching the code. This means keeping the costs down, there is no room for overhead, and by overhead I mean software, hardware and management expenses.

The principle goal of the first few blogs is to take the medium out for spin and see what it feels like.

Cheers,

:walt