DevOps

Monitoring Plan – AWS Style!

Lately, I’ve been reading some AWS documents in preparation for the SYSOPS certification and came across a great AWS monitoring best practice document.

This is such a great starting point for teams implementing a new monitoring solutions!

ANT – JUNIT – PARALLEL

Looking to speed up your builds by running your Junit tests in parallel with Ant?  With Ant 1.9.4, the Junit task now supports the “threads” attribute.  The default value is “1”, but can optionally be changed to the number of test threads desired that will be used for parallel test execution.

Note, when using this new attribute, you must set your “forkmode” equal to “perTest” and if you are upgrading to 1.10.x, Java 8 run-time is required.

faster.png

DevOps Interview Questions

Are you interested in applying for a new job?  Possibly a job in the DevOps field?  Or even hiring for a DevOps related position?  If so, read on….

The meaning of DevOps and the tooling associated with it differs depending on who you talk too or what company you work for.  Personally, I think the following categories cover many aspects of what a DevOps interviewee should be familiar with. (Obviously its not possible to be a expert in each one….)

  • Cloud (AWS, Azure, Heroku)
  • Orchestration (Ansible, Puppet, Chef)
  • Agile (Scrum, Kanban, Agile)
  • Programming (Python, PowerShell)
  • Containers (Docker, Kubernetes, Swarm)
  • CI\CD Tools (Jenkins, Git, TFS, Ant, Maven, Azure DevOps)
  • Collaboration (GitHub, Slack, Forums, Blogs, Meetups)

For the benefit of others and myself, I am going to start a github repo with some sample DevOps questions in the above categories.

github-octocat

Fabric and Reoccurring Tasks

So you have a handful of commands you execute weekly on multiple Linux servers.  You run these commands by opening a SSH tool like Putty, logging into the server, and then executing the commands.

Example commands:

  • ls /tmp/dropfolder
  • tail -10 /tmp/dropfolder/log1

With Fabric, you can bundle these commands and many others in a Fabric command file call fabfile.py.  Below is an example fabfile.py file containing just 1 task that will run (fabric.operations.run) the commands above.

from fabric.api import run

def dailycommands():
     run ("ls /tmp/dropfolder")
     run("tail -10 /tmp/dropfolder/log1")

You can then execute this file via the command line on 1 or multiple hosts with ease.

Example command:

  • fab -f fabfile.py -H host1,host2,host3 dailycommands

There are many many other things you can do with Fabric, so give it a try!

logo.png

Katalon – Docker – Linux

I’ve used Katalon primary in a Windows environment for running smoke tests.  This tool is relatively new, built on top of Selenium, and actively supported.  I highly suggest checking it out if you have some free time.  (Article describe Katalon pro’s)

So, the Katalon tests I run are launched from Jenkins and executed on a Windows 2012 slave machines via the command line.  These slave machines must have Katalon installed in order to execute the tests.

Tangent – Generating the Katalon command line string is beyond easy.

katalon.png

Installing Katalon on each Windows slave machine and remembering to do so in the future is a pain.  Well, as of Katalon version 4.8, you can now execute the tests from a Linux server via the Linux shell.

So, the solution I am thinking here is the following:

  1. Create a new docker image with Katalon installed and an ENTRYPOINT of ./katalon.
  2. Setup a Linux server as a Jenkins slave
  3. Install Docker on this new Linux server
  4. Pull the Katalon docker image to this new server
  5. Create a smoke test Jenkins job that will pull the smoke test files from Git down to the slave, and then run the docker container with the correct smoke test syntax included in the command. (Similar to this)

The benefits of this solution are numerous. (e.g. easily update Katalon versions, identical Katalon configurations between Linux slaves, easily recover from outages, etc…)

katalon

Brian Harry – DevOps Presentation

I was fortunate to have had the opportunity to listen to Brian Harry speak twice this week. (At work and at MHTA)  I have been a big follower of Brian since the early TFS 2005 days, so I was pumped!!!

His talk was about DevOps and his VSTS teams journey.  Below are some of the highlights I wrote down from his presentations.

  1. His team always strives to find the root cause of issues… Always!!!
  2. His team works in 3 week sprints.
  3. It takes his team about 2 weeks to push out VSTS updates to all locations.
  4. They push releases internally 1st which is a lot quicker.
  5. They have feature teams, with each feature team responsible for all aspects of there code.  (e.g. Build, test, deploy, production support, etc…)
  6. Their feature teams have dedicated roles that are responsible for troubleshooting issues in production .
  7. Brian uses VSTS to help planning his farm tasks.
  8. You can not put a timeline on your DevOps journey.  If so, there is a good chance you will fail.
  9. He highly recommended the book “Drive” by Daniel Pink!
  10. Merging is really expensive
  11. They have release branches and that is about it.  (In addition to master\mainline)
  12. More “Shift Left” testing, which mean more unit testing.
  13. Feature flags are a huge part of DevOps

Overall I really enjoyed listening to him and was able to congratulate him on the success of TFS and VSTS.

VSTS-2015.png

DevOps – 2 words that come to mind

So what are the 2 words that come to me when someone says DevOps?

  • Collaboration – This means that all teams practice strong collaboration between one another.  This doesn’t mean more email or messaging, this means sitting in the same area, participating in the same morning scrums, solving issues together, reviewing work together, etc…
  • Automation – This means looking at your build\deployment pipelines and other SDLC processes, and applying automation to them to produce predictable, repeatable, and reliable results.  (e.g. Automated CI deployments, automated notifications)

With collaboration and automation, we can continually delivery value throughout the SDLC.

Its really as simple as that for me.