I’ll be off on some coding adventures in the coming months. I also hope to catch up with a lot of people and their respective projects, learn a few things, and if it’s possible maybe teach a few people a thing or three about immutable infrastructure, lessons I’ve learned, and how to avoid infrastructure catastrophes while building the next bad ass awesome application. This blog entry is about the details of my logistics, and I’ll follow up with more details of the coding adventure along the way. For now: details, details, and details.
In this talk I’ll tell the story of our efforts at Home Depot, and provide bullet points and suggestions for helping you to acheive the move to open source practices in your enterprise. The benefits are huge, and overall it’s a lot more fun to boot!
Steps we took to get into the open.
Practices to take up and start using.
Things to avoid when moving to open source models.
How to make the most of things for the community and the enterprise.
Tooling, interoperability, services, and how to get it done.
Building Immutably to Continuous Delivery with Minimal Inputs
This workshop focuses on building a continuously delivered pipeline using Node.js (however easily transferable to Ruby/Rails/Java/Scala/.NET etc.). The workshop will trace the steps from inception to deployed application (with a domain pointed appropriately and all) that can then be developed against to continue whatever effort and intent of the developer(s)!
The parts: Application, Domain Name, Infrastructure, Integration, & Delivery
Build an Application: Steps for building & actually building a simple Node.js Application to deploy.
Getting a domain name, determining name servers & DNS servers, setting it up and getting it pointed at our application.
Setting up and determining the deployment scenario on AWS & discussion of other infrastructure choices.
Deploying the application through the complete process of code, integrate, test, build, deploy.
I’m super stoked about this talk, as I’m getting to co-present with Evan Brown. Evan’s a friend of mine since I met him a whiel back while he worked at AWS, however he’s now a Senior Software Engineer at Google. We’re going to tag team style this talk to bring you as much information as we can about organzing your infrastructure configuration and workflow.
My abstract for this talk goes something like this, “When starting with the various products Terraform, Packer, Vagrant, and others, it isn’t always apparent where and in what way one should organize the actual project. In this talk I’d like to delve into what I’ve done to organize solutions for development, production, and related pipelines. I’ll talk from my point of view and what I’ve seen others do to keep their workloads organized and their infrastructure and application pipelines clean and well organized.“
I wanted to get a continuous delivery process setup for Junction that could help everybody involved get a clear and quick status of the project. The easiest way to do this for a Windows 8 .NET Project is to setup a Team City CI Server.
This article covers what I went through to get the server up and running. In the next part I’ll cover troubleshooting that I went through to get a Visual Studio 2012 Window 8 C# Project building correctly on the server.
Finally, the last part is a small surprise, but suffice it to say I’ll be getting a completely different language and tech stack up and running which you’ll likely not guess (or maybe you will). 😉
Setting up Team City 8.0.3 (build 27540) using Tier 3 and a Windows 2008 Server, or not…
Setting up a Windows 2008 Server with Tier 3 is super easy, as you’d expect with a cloud service provider. Log into your account, click on “Create Server” to bring up the create server dialog.
Next enter the information and select a Standard server.
Click next and then make the last few selections.
Click Create Server and then sit tight for a few while the server is created. Once the server is created navigate back to the server information screen (I’ll leave you to get back to this screen).
On this screen click on the add public ip button to bring up the IP & port selection screen.
On the public IP screen select the HTTP (80) and RDP (3389) ports to open up. Click the add ip address button and again sit tight for a few. Once the server has the IP set then we can log in using RDP (Remote Desktop or on Mac try CoRD).
Next install the .NET 4.5 SDK. For the latest, it’s best to install the latest windows SDK that is available for Windows Server 2008 also.
Team City install
In the instructions below, you’ll notice everything is now Windows Server 2012. That’s because after installing everything on a Windows 2008 Server I stumbled on a very important fact. I’m working to put a build together for a Windows 8 Store Application, which requires a Windows Server 2012 (or Windows 8) operating system to build on.
I got a sudden flashback to OS-X and iOS land there for a second, but leapt in and wiped out the image I’d just built. Since I’d built it in a cloud environment, it merely meant spending a few seconds to get a new OS instance built up. So after a few clicks, just like the instructions above for building a Windows 2008 Server I had a Windows 2012 Server instead. There are, however a few steps to follow once you have a good Windows Server 2012 install. Once you have a good Windows 2012 Server up and running it should have a public IP, some memory, compute and storage capabilities. In the image below I didn’t give it a huge amount of horsepower for a few reasons.
It’s just doing builds, not computing the singularity.
If it can build on this, I’m doing good keeping the project clean.
I want to keep the build fast, keeping it on a weak machine and still having it fast also reinforces that I have a clean project.
I don’t need a successful build every second, the server gets used only during pushes by devs. If we get up to dozens of devs hacking on this, I can easily spool up and get a faster, more hard core heavier horsepower option up and running.
When Windows Server 2012 boots up the first thing that will launch is the Server Manager. We don’t really need that yet, so just ignore it, close it or move it to the side.
The first thing we will need is Internet Explorer, so we can download Chrome or Firefox. Internet Explorer is wired up with high security so the first thing it will do is explode with messages about sites not being in the right zone. It is, hugely annoying. So add each site to the zone and head out to the web to pick up Chrome or Firefox.
In the following screenshots I didn’t actually download Chrome or Firefox first, but instead downloaded TeamCity. I advise getting Chrome or Firefox FIRST and then downloading TeamCity with one of those browsers. Life is dramatically simpler that way.
I know one can turn off the security settings in IE, but it’s just dramatically easier to go and use one of the other browsers. Just trust me on this one, if you want to turn off the security features in IE, be my guest, I’d however recommend just getting a different browser to work with.
Once you’ve got your browser of choice and Team City downloaded, run the installer executable.
Leave the components checked unless you have some specific goal for your server and build agents.
In one of the subsequent dialogs there is the option to run the server under the SYSTEM account or under a user account. Since this is a single purpose machine and I don’t really want to manage Windows users, I’m opting for the SYSTEM account.
After everything is installed navigate in a browser to http://localhost. This will automatically direct you to the TeamCity First Start page.
At this point you’ll be prompted to ok the EULA.
Then you’ll be prompted to create the first Administrator user.
From there you’ll be sent to the TeamCity interface, ready to create a new build project.
Click on Projects at the top left of the screen and you’ll navigate to the Create a Project dialog. Click on the Create a Project link to start the process.
Once you’ve entered the name, project ID and description click on Create. This will bring you to the next step, and to the general tab of the project. On this screen click on Create build configuration.
Now create a name, enter the config id, and click the VCS Settings >> button to move on to the next step of the process.
In VCS Settings leave everything as default and click on the Add Build Step >> button.
Now select the Visual Studio (sln) option from the Runner type and give the dialog a moment to render the options below that. They’ll appear and then enter the Step Name, Visual Studio type needs to be set to Microsoft Visual Studio 2012 and then click on Save.
From there you’ll be navigated back to the Project Build Steps screen. On that page you’ll see the build step listed. We’ll have one more we’ll need to add in a moment, but for now click on Version Control Settings again.
On this page click on the Create an attach a new VCS root.
Now select Git from the dialog and wait for the page to populate the form settings and options.
Now enter the correct Fetch URL to the Git repo (which on github looks something like https://github.com/username/gitrepo.git and is available to copy and paste from the right hand side of the repo page on github), enter the appropriate default branch to build and an appropriate VCS root name and VCS root ID. Once that is done click on the Test connection button.
Click save and now navigate back to the Build Triggers screen by click on the #5 option on the right hand side of the page. You’ll be navigated back to the magical Version Control Settings screen where you now have a few more options available and a VCS root available.
Now an Add New Build Trigger dialog appears to add the trigger. I set it to trigger a new build at each new check-in. The TeamCity server checks frequently to see if a commit has been made and will initiate a build. Another way however to setup this is to not add a trigger and instead go to Github (if you’re using Github) and setup a push trigger from Github itself. That way every commit will initiate a build instead of the TeamCity Server, which knows nothing about the actual status of the repo until it checks, giving a more timely build process to your commits & dev workflow.
Now, one more build step. Add the NuGet Installer (which is included with the TeamCity Build Server, check the docs for TeamCity 8.x for NuGet Installer and NuGet for more information). For our purposes once you’ve insured that the NuGet Installer you need is available add a new build step. Select from the Runner Type NuGet Installer and the respective form will populate below.
Once the step is added, click on Reorder Build Steps under the Build Steps list and a dialog, specifically for reordering the build steps will appear.
Reorder the steps so that Getting NuGetty (the name I’ve give to it, click for a full size image) will be run first.
At this time you now have all of the steps you actually need. You’ll be able to go back to the main projects screen and built the project.
When you do this however, if you’ve actually set this up to build a Windows 8 Store Project you’ll get a build failure. Which is a total bummer, but that makes for a great follow up blog which I’ll have posted real soon! For now, these are great steps for getting a modern ASP.NET, Java, Maven and a whole host of other builds up and running. For the solution around the Windows 8 Store Project keep reading (subscribe on the top right hand side to the RSS!) and I’ll have that posted up real soon.
Step #1: Continuous Integration
The first thing I did was setup a solid node.js project that works on Travis CI (Continuous Integration). This is a pretty quick process. First create a directory and add an appropriate .gitignore and README.md file.
The mate command is merely textmate, use whatever you’d like though to create the files. I also use Sublime 2 and other things, textmate just happens to be the poison I often choose from the command line. The .gitignore has the following to take care of WebStorm and other files that might pop up.
The README.md I just put the following in. You don’t really need this, but I’m showing you what should be put in a minimal project. In addition to being a good practice, we’ll need the README.md file for plugging in Travis CI in a few steps.
So that’ll get the continuous integration via Travis-CI for NameFactory up and running, with a Github NameFactory Repository that is ready for the name generation code to be added. For my next blog entry I’ll leap into some generation strategies, dig up some good name lists (if you know of any, leave a comment w/ a link), and work on figuring out the fastest way to generate names.
Once that’s done, it’s time to setup some distributed databases.