Tag Archives: Version Control

Ansible Playbooks – Externalization and Deduplication

Image result for ansible

Externalization and Deduplication

Developers who understand the concepts of modularity and deduplication should immediately recognize the power behind being able to include settings and commands from external files.   It is seriously counter-productive to maintain multiple scripts or playbooks that have large blocks of code or settings that are exactly the same.   This is an anti-pattern.

Ansible is a wonderful tool, however it can often be implemented in counter-productive ways.  Lets take variables for example.

Instead of maintaining a list of the same variables across multiple playbooks, it is better to use Variable File Separation.

The Ansible documentation provides an excellent example of how to do this.  However I feel that the reasoning behind why you would want to do it falls short in describing the most common use-case, deduplication.

The documentation discusses the possible needs around security or information sensitivity.  I also believe that deduplication should be added to that list.  Productivity around how playbooks are managed can be significantly increased if implemented in a modular fashion using Variable File Separation, or vars_files.   This by the way also goes for use of the includes_vars module.

Here are a list of reasons why you should immediately consider a deduplication project around your Ansible playbook variables:

Save Time Updating Multiple Files

This may seem like a no-brainer, but depending on the skills and experience of the person writing the playbook, this can become a significant hindrance to productivity.   Because of Ansible’s agent-less and decentralized manner, playbooks can be written by anyone who wants to get started with systems automation.  Often, these can be folks without significant proficiencies in programmer-oriented text editors such as Vim, Emacs, or Eclipse – or with bash scripting experience around command-line tools like awk, sed, and grep.

It is easy to imagine a Java developer without significant Linux command-line experience opening up one playbook at a time, and modifying the value for the same variable, over and over… and over again.

The best way for folks without ninja text-editing skills to stay productive is to deduplicate, and store common variables and tasks in external files that are referenced by multiple playbooks.

Prevent Bugs and Inconsistent Naming Conventions

In a perfect world, everyone would understand what a naming convention was.  All our variables would be small enough to type quickly, clear enough to understand its purpose, and simple enough that there would never be a mis-spelling or type-o.  This is rarely the case.

If left un-checked, SERVER_1_IP can also be SERVER1_IP, Server_1_IP, and server_1_ip.  All different variable names across multiple files, referencing the same value for the exact same purpose.

This mess can be avoided by externalizing this information in a shared file.

Delegate Maintenance and Updates to Variables That Change Frequently

In some environments, there may be playbook variables that need to change frequently.  If these variables are part of some large all-encompassing playbook that only some key administrators have access to be able to modify, your teams could be left waiting for your administrator to have free cycles available just to make a simple change.  Again, deduplication and externalization to the rescue!  Have these often-changing variables externalized so that users who need these changes immediately can go ahead and commit these changes to very specific, isolated files within your version control system that they have special rights to modify.

Cleaner Version Control History (and therefore Audit History)

If you have the same variables referenced by multiple files, and you make changes to each of those files before you commit them to version control, then your version control history can become a complete mess.  Your version control history will show a change to a single value affecting multiple files.  If you come from a software development background, and are familiar with the concept of code reviews, then you can appreciate being able to look at a simple change to a hard-coded value (or a constant), and see that it only affects one or two files.

I hope the reasons above convince some of you to start browsing your playbook repositories for possible candidates for deduplication.  I really believe that such refactoring projects can boost productivity and execution speed for individuals and teams looking to push changes faster while minimizing obstacles around configurations shared by multiple systems.  Send me a note if this inspires you to start your own deduplication project!

Why You Shouldn’t be Sharing “Live” Documents by E-mail

 

If you and your team, in 2013, are still sharing Microsoft Office (Word, Excel) documents via internal corporate e-mail, I’ve got news for you.  You’re doing it wrong.

“Live documents” are documents that are actively being updated and collaborated on by multiple people.  Collaborating on these documents by e-mail is a process that you should avoid.  It is a process that can eat away at your team’s productivity precious minutes at a time, and can severely impede your team’s work-flow and ability to stay synchronised.

I’ve been involved with projects where this method of collaboration was adopted.  Whenever I recognize this to be the case, I would immediately share my concerns, and try to suggest better ways of getting the team organized. There are always better ways to do it.

One of the biggest problems with e-mail document sharing is that there is no tracking or accountability.  There is no way to easily know what version of the document you have in your possession.  Is it the latest?  Perhaps it’s new enough?  Ever had to find an email with a document attachment, and ended up trying to craft clever little search terms to search your inbox?  Even if you find the document you were looking for, there is no way for you to know whether it is the last official revision, unless a system is implemented to allow “official” versions of the document to reside in a central location.

If there is a point-person in charge of managing this kind of set-up (for example, a simple system implemented with shared folders), and the maintainer ends up leaving the company for any reason (vacation, short-term disability, lay-off), then you still end up in a bad situation.  Without someone actively maintaining the structure of the document store, things will end up getting messy very quickly.  Users will begin storing documents in arbitrary locations (whatever feels right at the time), and before you know it, you will have to start yet another document archive clean-up project.

Version control is ubiquitous, and it is here to stay.  Any company (in any industry, not just IT) not seriously considering a process for document revision control should at least make it a point to have the discussion at least once a year.  You may find that your current document handling processes are actually a significant time waster, and that implementing a document management system could save you a lot of time (or money) over the long run.

There are many document sharing and collaboration technologies available today.  Some of the more popular include Sharepoint (if you are a Microsoft shop) or Documentum.  There are also many open source (free) packages, such as Drupal, Joomla, and Liferay.  There are even projects like Etherpad that make collaboration just plain fun.  You can also roll-your-own (if you are so inclined) by developing a custom system on top of foundational version control software such as Git or Bazaar, as I personally have done in the past.

Do your research when considering a content management system.  Some important considerations you might want to make include:

  • Is it easy to set up?
  • Is it easy to use?  Does it blend well with our team’s work-flow?
  • Is it safe?  Is it easy to make backups?
  • What kind of security mechanisms does it have built-in?
  • Is it easy to get our data out of the system (strong import/export functionality), in the event that we decide to move to another system in the future?
  • Is it cross-platform, or does it tie us to a specific platform (operating system)?
  • Is the cost worth the investment for a company our size?

The important thing here is to start thinking about it.  Be open to evaluating multiple products before you decide on a system that blends best with your organization’s work-flow. Software is about solving problems, which includes eliminating routine and time-consuming tasks.  If your company is not continually looking at new ways to improve efficiencies via clever (and practical) software implementations, then it will eventually be left in the dust as more efficient start-ups and entrepreneurs bring their shiny new productivity platforms to the game.

Braindump: WxWidgets, Version Control, and Firefox Bookmarks

WxWidgets GUI Programming

I’ve been thinking about creating an application using the WxWidgets GUI API.  I’ve read a lot about it, and many seem to really enjoy the results of the applications they’ve created with it.

For my own purposes, I’ve been looking for the ideal GUI API that would allow me to quickly create cross-platform desktop applications for Windows and Linux platforms (Mac would be a bonus).  I’ve looked at QT, GTK, and MingGW.. but I’ve been turned off because they don’t seem to have strong Perl and/or Python bindings (although Perl strong with Tk, I’ve heard).

I’ve tried a small test Python program with WxWidgets (GTK version), and was pleasantly surprised at the simplicity of the code.  I think I’m going try some other tests, this time using Perl, as I want to note the differences in complexity between Perl and Python code.  Currently, Perl is my canvas of choice ((Being that I see programming as an art, more than anything else)).

Continue reading Braindump: WxWidgets, Version Control, and Firefox Bookmarks