Practical Technology

Trying to work out a few things right now: Where do I draw the line between 'do this in Chef' and 'do this from Go'? How do you 'template' Chef recipes? Where do I draw the line between 'do this using Chef' and 'do this using Chef but via PowerShell'? Regarding #1 , I can do pretty much everything in Chef...but then you lack the visibility and variables from Go.   This should be cleared up by figuring out exactly what we want the Go deploy pipeline to look like - where do we need the milemarkers to sit?  Or maybe we just need one stage with really detailed error handling? Regarding #2 , right now I have a cookbook for 'WebApp1', and it will only work for WebApp1, not WebApp2, or 10, etc.  I imagine there is a simple method here.  (might have found it: #{cookbook_name}) Regarding #3 , it really comes down to 'I know this can be done (and how to do it) in PS, but figuring it out in Chef will take time'.  For the P...

The build process is now 100% functional! Except I broke it.  For some reason the GO agent started only using the active directory NicelyFormattedName...which of course broke the auto-login, because the Linux-side name is all lowercase.  After changing the environment variable and deleting every cache I could find, ended up just changing the AD account to all lowercase.  Fixed.  :S Now it's fully functional!  Except the additional test branches dev gave us won't build like the first one. Good news is that we are now Chefing - and this part is what I've really been looking forward to.  After a LOT of reading, it seems this is the recommended practice: Use a 'roles' cookbook - because versioning EVERYTHING is super important, and roles are not (at this time) versioned Environments allow you to restrict versions Try and keep things as simple as possible - limit the 'blast radius' of bad changes Here's how we are (at this time) structuring thin...

Long story short, even if you have the GO Agent service (Windows) running as the correct user, commands will still pass as 'SYSTEM'.  Could not figure out how to change this, or get SYSTEM to use the id_rsa for the correct user (3+ hours of Google and trial/error).  So, here's an example command, old vs. new: OLD cmd /c powershell c:\scripts\BuildFileMove.ps1 %GO_PIPELINE_NAME% NEW cmd /c powershell $pass = convertto-securestring %GO_SHELL_PASS% -asplaintext -force;  $mycred = new-object -typename System.Management.Automation.PSCredential -argumentlist "%GO_SHELL_USER%",$pass; invoke-command -computername localhost -ScriptBlock {c:\scripts\BuildFileMove.ps1 %GO_PIPELINE_NAME%} -credential $mycred The stuff that was failing, and how we figured it out: We're using Git for Windows (the command line, full bash integration), and trying to do push/pull The powershell scripts all run fine when done via the ISE/PS prompts, but when you try to get the...

One of my client's sites was hacked the other day - new experience for me, so thought I'd share in a somewhat linear format. The developer who wrote the site did so using Drupal, and apparently a few weeks ago a pretty big vulnerability was found (something to do w. PHP). The site is hosted by Network Solutions (UNIX web host package) - (NS hereforth). There is no customer data held on the site, it's just informational & a few PDFs NS detected that the site was hacked, shut it down, and sent an email to the primary contact. Primary contact was someone who used to manage the account - I was never made primary (for whatever reason - obviously THIS is why having it set correctly is important) Client called saying their customers were reporting an offline site. The NS splash page simply said 'invalid domain'. I called NS after triple-checking NS account status & domain validity. NS confirmed account status was OK, transferred me to web host division -...

Because of how I'd planned on setting up pipelines, the question arose: What do you do with branches? With that process, you would have to create a fresh pipeline for each branch - the idea being your build repo project list is 'clean' for each project.  Well after discussion, this didn't make much sense, so we now will simply have a pipeline per project (app/svc/site), and we simply adjust the pipeline material project path on each build request.  In other words, from a build/deploy point of view - we don't care if it's a trunk or branch request, just give us the project path and we'll build it.  Simple process change! The 'downside' to this is if you need to push out an emergency build, it'll 'interrupt' anything currently running in the environment chain.  This is primarily due to us only having one of each environment.  Eventually, with rapid build/teardown environments, this will go away. It also became clear as I was testing t...

So due to a number of reasons I won't disclose, the process needs to change.  Slightly more manual, but if GO offers the option, should be mitigated reasonably well. Essentially the applications use stored procedures and whatnot in the DB layer - these are shared to recycle code.  Unfortunately it means that we cannot simply have a pipeline for each app/svc - items must be updated together (and taken offline to do so).  Something for our architecture review board meetings... Anywho...here's the new plan: New sprint starts - PM informs us that XYZ apps/svcs are being updated We create a single new pipeline for the SQL scripts Then create a 'sprint dashboard' page with the relevant individual pipelines When they are ready to build, we can do each item individually (or together) When they are ready to deploy, we run the SQL pipeline This stops all relevant services/sites and runs the SQL scripts The buildmaster then runs the other (remaining) pipelines on the ...

Here's a broad overview of the process.  We are surprisingly close... Code for the project (webapp/website/windows service) sits in TFS The GO build agent is on a Windows server w. Visual Studio - it builds the project Have the config files changed?  If so, this process is still manual - thankfully rare, should just be an onboarding task On the build agent, git commit the built files and config files After the commit, get your latest version number and apply a label into the TFS project noting the associated git hash (so when troubleshooting, we say 'it's this git hash version we're running', and they say, 'oh, what label in TFS?' - now we have an answer!  (co-worker came up with this idea) Git houses built project files and project config files Git also houses the Chef config files Chef will be run to re-configure IIS (if necessary), operate services/appPools, and...dun dun dun...run a git fetch! (or git clone, not sure yet)  Bam!  New code! Ext...