So what would a book on management on a Navy ship have to do with DevOps?
Well it’s really a book on how Captain Michael Abrashoff created a collaborating organization on his ship while in the US Navy. As a result, he brought his ship from the bottom 3rd in the Pacific fleet to the best ship in the Navy. He increased his crew re-enlistment rate from 8% to close to 100% during his time on the USS Benfold.
The Military is know for it’s highly rigid command structure and for that matter its traditionally restrictive culture that discourages contribution and change. On top of that, you don’t get to choose your crew or your boss. Does that sound like a place you might be working for?
He created a collaborative culture by doing the following:
1 – See the ship through the eyes of the crew 2 – Communicating often 3 – Create discipline by focusing on purpose 4 – Listen aggressively
He also outlined how he did this in a restrictive military culture.
He would find ways to:
1 -Use dumb rules to his organizations advantage.
2 – Shelter his crew from the higher ups bad policies.
3 – Make his superiors look good and get latitude to run his ship.
Although this book has been out for a while (2002), these ideas presented in this book can give you some ideas on what you can do to implement the collaborative culture of DevOps in your organization.
Soft skills like communications and management are often overlooked by people in Software Development and Technical Operations. Take the time to improve these skills as it will not only enrich your workplace, but enrich your life.
If you have any suggestions or ideas, feel free to let me know.
The mantra of DevOps (Development Operations) is Infrastructure is Code.
For those who are not familiar with DevOps, it is a culture and philosophy of computer and network infrastructure management geared around development and delivery of software and services. DevOps uses tools geared towards automation of infrastructure, delivery of software and services. Ansible is one of those indispensable tools used in DevOps. With Ansible, you can manage your whole network infrastructures , deploy and manage virtual machines, install and configure VMs, provision and update software and services, etc. Written in python, and the configuration files are “programmed” in YAML (Yet Another Markup Language). It is a easy to learn tool for mass provisioning of Linux, Windows, Mac and virtual infrastructure using scriptable command line.
Windows operating system is ubiquitous and is probably one of the easiest, lowest cost hardware/software combinations to get for your testing and development and production environment.
The Windows Dilemma
However if you like me, are running Windows, there is one problem, Ansible does not run on Windows. The developers of Ansible have no intention of porting it to Windows (at this time). Even though, there “is” a way to use Linux like libraries on Windows (using things like CygWin) , however, it’s not very stable. You need a stable platform to do mission critical work. So, how do I run Ansible in Windows?
Introducing Vagrant
The answer to this dilemma is to use Virtualization. “Wait a minute…”, you might say, “Isn’t this a clunky and bulky way to run a tool by getting a clunkier interface to run it on?” This is where a virtualization environment for developers like Vagrant comes into play. Vagrant, from command line allows you to do some cool things:
1 – Use your favorite Windows based editor to edit your playbooks in which you can make changes to your files THEN run them without repackaging the image (as in the case of Docker).
2 – With command line within PowerShell, QUICKLY spin up your Linux VM to run Ansible.
3 – From the same command line, enter the Linux VM command line and run Ansible commands and run your playbooks.
4 – If you want to run the Vagrant VM for a dedicated task involving Ansible, with one command, you can do just that.
For those not familiar with Vagrant, this is a piece of cake.
How to set up Ansible in Vagrant
For the purpose of demonstrating how to do this in Windows, I will show you how to do this in a Windows 7 SP1 machine. I will also assume you are running the latest version of VirtualBox hypervisor. Vagrant will also work with VMWare and HyperV and other versions of Windows (7/8/10), but this will be left (for now) as an exercise you can do on your own.
Also, my preferred way to add software to Windows machines is to use a package manager like Chocolatey. Using automation with package management is the DevOps way. Follow this link for instructions installing Chocolatey.
3 – Download this vagrant file from the git repository and unpack it. This is a Vagrantfile template. You can use git to get the file.
4 – Change directory to vagrant directory and run “vagrant up”
5 – Access VM shell, run “vagrant ssh” It will take you into a Linux shell.
6 – To exit out of the VM shell, type ‘exit’ and hit enter. You will be back to the powershell command prompt.
7 – To shut down vagrant and the VM, run “vagrant halt” and it will shut down the VM.
I would recommend reading the README.md file in the directory for additional details.
How do these files work?
This is not a full tutorial on how to work with Vagrant, just enough to get you running with Ansible on Windows. We may cover the particulars of Ansible and Vagrant another time.
What is a Vagrant file?
The Vagrantfile tells vagrant how to provision the VM. The VM will be installed with Python and Ansible. It’s a file written in the Ruby programming language. It’s pretty straightforward how you can configure it to work with your development environment. Anyhow, from here, you can experiment with Ansible on the VM itself.
Once you access Ansible through Vagrant, you can start using Ad Hoc commands and writing playbooks for Ansible and executing them right there. Do some searching on the internet on what you can do with Ansible. It’s a very powerful tool.
That was quite a bit of info, how do I wrap my head around this?
That is the unfortunate nature of any profession, especially the technology profession. You need to know many different tools and concepts in order to use them, and many of the tools by themselves don’t make much sense until you find a context to use these tools. Each one of the tools and technologies I used in this intro have their own use in the DevOps area. You have to dive right in and play with them in order to find out how they can help you to use them in your own particular situation. I may cover each of these tools individually in a future article.
Originally, I was going to write about Ansible and how to run it in a Windows environment using Vagrant, but as I started to write the article, I found that I had to describe how these tools were used and developed around the culture and philosophy of DevOps. Then, it occurred to me, I needed to describe what is DevOps. According to Wikipedia, DevOps is a software development methodology that combines software development (Dev) with information technology operations (Ops). Of course, I’ll use DevOps definition in a broader sense and more oriented towards operations.
Why should I care? Isn’t systems administration and DevOps the same?
Not exactly. Being brought up on old school Unix Systems Administration, I remember when machines consisted of dedicated hardware(CPU, Memory, Framebuffer, hard drive, etc.) software and network switches and routers. I would spend hours configuring individual machines using scripts or installing software (or compiling it) one machine at a time. I would be working with a team of people it seems firefighting. Keeping up with the demands of the users and their needs for additional resources…well was a pain. Then we turned the corner with virtualization where your machine is just a disk image sharing space on high powered hardware, more efficient, easier to use programming languages such as python & ruby (though this can be debated, but these languages are easier than programming c) and working towards automation. Mass on demand Virtualization is now called “cloud computing” or what I call Commoditized Virtualization. You can get VMs on demand and pay for what you need even by the hour. Out of these merging of technologies and software development methodologies (such as Agile) is where DevOps finds its origins.
Contrasting Systems Administration with DevOps.
Systems Administration tends to focus on being a tech…that is a power user who loads and configures software and plugs in hardware into the system. DevOps on the other hand focus on programming and automation of the system and network infrastructure. The mantra is “Infrastructure is Code” where you write and run code to make running the systems and network infrastructure more predictable and controlled.
System Administration tends to be reactive. That is you plug in the hardware/software and find out if it works and fix it as you go. DevOps is proactive in its approach. Use automation in a consistent and predictable way by using tools to test in a development environment before releasing it into a production environment.
System Administration tends to follow a “waterfall” approach to planning, getting requirements and deployment. You tend to make big expenditures of capital, time and resources up front. You fix it as the complaints come in. DevOps approach is more “agile” with many smaller changes to the system with plenty of user feedback BEFORE it’s all rolled out as well as DURING and AFTER the rollout.
While your company or organization may not be a software development house, i.e. you may be a web design company or your supporting your own companies internal network, you WILL benefit from adopting a DevOps approach as this can be applied to:
1 – Rolling out new software to your internal desktop users and keeping them current.
2 – Keeping your customers websites updated using automation tools.
3 – Being able to show management (and other stakeholders) what is accomplished and what is needed. You keep them in the loop.
While this is not ment to be an exhaustive treatise on DevOps, this should open your eyes to what is useful and what is possible.
In a world where fresh food goes stale then rots, pets are born, grow old and then die, software is perishable. What do I mean by that?
Requirements change
Isn’t software something that once it’s written just does it’s task and doesn’t change? Yes, that is true, but the REQUIREMENTS needed to keep software useful will change over time. Often the changes can be swift and rapid. This can get you and your business into trouble if you don’t keep your eye on it.
A way to look at software is what reason did you get the software in the first place. It filled a need, a requirement.
For instance, I get an accounting package…lets say KwikyBooks. I get the package for my accounting needs. Well, what are my requirements?
1 – Generate invoices of my customers.
2 – Take payments and track this information.
3 – Generate various reports.
Hidden REQUIREMENTS
However, there are HIDDEN requirements that may not be obvious until you start using your software:
1 – What kind of hardware does this software run on. If you can’t obtain or afford the hardware, the software will be useless.
2 – Is the software secure? If you can’t keep your confidential business data safe, you will lose customers because they can’t trust you to keep the information safe. It’s just a matter of time before someone or something hacks your system.
3 – Is the software keeping up with industry standards and practices? Is it compliant with Federal, State and Local laws? E-commerce businesses, depending on it’s size, for example may have to track sales tax in EVERY STATE it sells to. Every year the Federal and Local government adds new laws and regulations that affect accounting and Tax laws. Having software that is non-compliant with industry standards and laws can cost you money and even your business.
In the same way, even though your software you have purchased or have developed for your company or customers may fulfill your original requirements, the HIDDEN requirements often will change because the software doesn’t change with time.
Prepare for Hidden Requirements
With this in mined, here is what I’d suggest you do when you either purchase software or have it developed:
1 – Check on the stability of the developer or company you are getting your software from. Even if it’s AWESOME software, if the software developers who wrote it go away, you can’t get the software HIDDEN requirements fixed. If your working with an independent software developer, I would recommend you use a well known open source framework and languages. In the worst case scenario, you can find a python or java developer to take over development ant maintenance of your software than something written in let’s say a Esoteric programming language or a language that is not as common to use these days (i.e. Fortran, Pascal, Assembly, etc.)
2 – Get or obtain a service contract or maintenance agreement for the software. With this in place, you keep the software developer vested to keep your software up to date.
3 – Periodically review your requirements and discover what your HIDDEN requirements are and get them addressed.by the developers. The HIDDEN requirements are usually found in changes in these three categories:
a – Industry rules and standards – Software is codified expertise that follows the rules and standards of your industry. b – Laws (Federal, State and Local) – Legal requirements affecting your industry or profession. c – Technology – New technology and advancements, including updates and security fixes.
I would recommend you work with your software developer or software company to help you keep track of these areas that can affect your software requirements. Incorporate this process if you are working with Agile software developer.
In summary, please re-examine your software requirements regularly and make sure you keep you software fresh. Don’t allow your software to perish along with your business.
Ok, you just created the Javascript/HTML/CSS code you want to use for your WordPress site on an HTML page. How the heck you get this into your WordPress page? Well, with the magic of plugins.
What are plugins?
Plugins are a file and directory structure used by WordPress to add code to your WordPress site. Here is an example of the directory structure .
The main file that tells WordPress plugin how to run is movetotop.php
The other directories and files are:
README.md – Markdown readme file.
assets – image files and fonts used by plugin. Fontawesome is used here.
css – Cascading Stylesheet used by plugin. The stylesheet totop.css lives here
js – JavaScript files used by plugin. The JavaScript totop.js file code is here.
Creating the plugin.
Chop it up.
First things first, we will “chop” up the HTML and JavaScript code and place it where it needs to go.
To make the file naming consistant with the plugin name, I renamed the custom.css file to totop.css and custom.js to totop.js. Otherwise, there is no change to the content of the files or code enclosed.
I also separated the fontawesome files into assets/fontawesome-5 directory so to better organize these assets.
Movetotop.php and how it’s organized.
The real magic of WordPress plugin is found in the movetotop.php file.
There are three sections found in a plugin file:
Header. This is commented header enclosed is /* */
add_action/add_filter – this tells WordPress to execute scripts to add the CSS/HTML/JavaScript files into the HTML generated by WordPress sent to the web browser.
Function(s). This is the scripts that injects the CSS, HTML or JavaScript files when called by add_action/add_filter.
Well, let’s go into how this file is created and what is used.
This is self explanatory. Without this information, the plugin will not show up in the WordPress plugin dashboard.
The hook function
The hook functions add_action/add_filter – This adds the CSS/HTML and JavaScript file into WordPress hooks. Generally, hooks are the location of the content.
(Location of content(hook), Function content to be applied).
There are MORE hooks than what we’re using here (over 1,000+ hooks, see this link for a comprehensive list) which do a variety of things. For this example we’re just sticking to the basic ones.
Function
The function that injects the content inside the HTML.
This function injects the css/totop.css file name and location and outputs it as a text HTML reference. This is then called by the hook function and injected in the location (hook) specified.
Wrap up.
That’s how you develop a basic WordPress plugin. We didn’t cover other stuff like an admin backend interface with configurable parameters. That we may do another time.
