test_it && commit_it || reject_it
Using a pre-commit script when committing code makes sense and fits with every respectable dev-ops model.
The goal is to have respectable code before it lands in a repository. Git makes this very easy through the use
of “hooks”. If you look in any of your git project directories you will find these files in the ./.git/hooks/ directory:
VIM is a standard for me. My UNIX career hung on my “vi” savvy which I learned appreciate from mentors who encouraged me to learn the tips and tricks of using vi. My learning curve with vi/vim has never leveled off, but rather, always gives me new features and tricks that energize me again. The latest vim “trick” is ALE (Asynchronous Lint Engine).
»Vim (or vi in the anceint past) has been my partner in getting things done. Like an rich tool it has lots of features that go untapped or undiscovered. A few days ago I decided I wanted a script within a tempate to help build the “front matter” to my markdown (.md) files.
The front matter looks like this:
+++
author = ""
comments = true
date = "2018-07-15 14:45:19"
draft = false
image = ""
share = true
# slug =
# tags = [ "tag1", "tag2" ]
title = "vim_scriptable_templates"
+++
The challenge was to have vim write in the date for me in the needed format. And if you use hugo as your static web site generator as I do you may have found that it will silently ignore a new markdown file if the date is not formated correctly. It some testing to discover that but the bottom line is that I needed a way to script it for to avoid mistakes.
Research to me to this tip source: vim embedded scripts
»Python Fabric is a denatured version of ansible and, if you enjoy python, fabric makes a small scale devops strategy a whole lot less painful. Combined with hugo static website generator, fabic makes testing and promoting a website a whole lot easier.
I have struggled in the past with one challenge that made promoting website code from my workbench to dev, staging, and ultimately production tricky. The matter of URL always played havoc when I sent code up from one server to another for testing. Hugo offers a simple solution. When I promote website code it goes through this workflow process:
»I have wrestled with ansible for too long. It is an awesome tool but you need to learn the syntax of three different languages (ansible, yaml, and maybe some python) to hold it down and control it. Every time I go to use it I have to learn how to do what I need to do. But the most frustrating aspect of ansible when learning to do something new is that your first attempt rarely succeeds - at least for me. So you resort to “force programming” to get through it. By “force programming” I mean you try this and that and then something else until it works, and I end up with a hodgepodge of debug lines commented out.
»