We all know that feeling: time is of the essence. Deadlines, quality time with your loved ones and still time for toy projects to keep yourself up-to-date – everything demand time but the day can’t offer us more than 24 hours. And don’t get me started on sleep.
But wait, there is more. Our repositories bubble over with $stuff, different projects use different build tools, CI isn’t keeping up, deployment processes… AAAAAhhhh.
But fear not fellow code-warrior. With a few little helpers, you can save yourself and your team a lot of time and free up these rare free-time hours.
Automate All The Things
It is not all about servers when we talk about automation.
Onboarding is always a pain. Getting everything set up on your developer machine, getting access to all systems and getting that extra little helper tool no-one knew about before joining that team but is saving everyone so much time.
Well, on a server more and more companies go down the automation route which makes sense and saves tremendous amounts of money. But for some reasons, I barely came across an automated set up of our local machines.
The easiest and least painful way of achieving this is to use Ansible. All it needs is Python. That’s it. And all developer-oriented operating systems come with Python pre-installed.
Fair enough, you also need the versioning tool of your choice to get the latest set of playbooks, but you need it anyway.
Want to have a look for yourself? Ansible’s documentation is neat, but there are a lot of fantastic playbooks available already. For our Mac-fans, check out the Mac Development Ansible Playbook and for our Linux warriors have a look at this Ansible Ubuntu GitHub repository
Paired with the next tip the rest is just one
make call away.
I am not kidding you, and yes, we are still in the 21st century.
This is a hack I came across at one of my previous places. And trust me, I am sure your reaction is pretty similar to mine.
So, let’s put that prejudice aside and look at from a practical view.
Make is around since, forever. This makes the tooling pretty awesome and easy to use. Nearly all operating systems bring shell completion (if not, please go and install WSOL or Git Shell). Sure, we can install the needed bits and bobs for our favourite JVM-language build and dependency management. But it requires extra time and is sometimes not that straightforward.
On top of it, in nearly all projects I worked in, there were multiple projects, using different build tools that need execution in a particular order. That order is easily achieved on a CI server, but locally it is an entirely different story.
Out of the sudden, running
make in all of your sub-projects doesn’t seem so silly anymore, doesn’t it?
It also makes the life of your CI/CD set up easier. All a CI server needs is the correct set of targets.
Here is an example for a
Makefile I created to build one of my pet projects easier on my machine and my CI:
In Makefiles, the first target found is the default one. So, executing
make with this Makefile is the same as running
all target depends on most of the other targets. This is for convenience and entirely up to you, how you organise it. The most important thing is that all your projects should have a sensible default target that compiles the whole project in the correct order.
Why? Well, because this way, even the new junior developer who just joined can get everything compiled and tested quickly.
And yes, your developer machine automation project should have a Makefile and the default target should set up everything with sensible defaults.
Use CI for Your Pet Projects
You hopefully use a CI in one way or the other for your main projects at work. But going through all this trouble for your pet project? You want to hack away, possibly create a showroom for potential future employees.
Well, fear not. There are so many great CI-as-a-Service services out there to help us. And as long as we code in the open, they won’t even cost a thing.
One of the best-known services is Travis CI. It is simple, straightforward and surprisingly flexible.
By default, just adding a .travis.yml to a branch of your project and signing up with our GitHub account is all it takes.
Try adding the following config to your project:
language: java # if you already added a Makefile, simply add the following line script: make
All that’s left is to commit everything and push our branch with the shiny new YAML configuration file.
Easy, wasn’t it?!
And as a reward, we can add a Build-Badge to our project README.
All These Dependencies
Another pain in the back is keeping ahead of security issues.
Even in our pet projects, you should make sure you are not relying on vulnerable dependencies. Who knows, maybe our project becomes a dependency for someone else in the future?
Checking all the dependencies, especially the dependencies of your dependencies and then the dependencies… is nearly impossible for a single human being. The dependency tree is growing way too much.
Thankfully, there is a service for that. It is called Snyk and guess what, to get you covered you do not even need to borrow Santa’s platinum credit card.
It is free for open source projects (defined as openly available on GitHub), and you get a fair number of checks per month for private repositories.
This is not limited to GitHub of course. You can choose from quite a variety of services or use the CLI tool and
make it part of your build 😉
The CLI and all its dependencies are already on your machine, as your local environment automation script took care of it!
Is There More?
There is so much more out there that can help us be more productive.
Frameworks, libraries, services, IDE plugins and even command-line frameworks like Oh-My-Zsh are ready when you are.
In essence: We should stop reinventing the wheel over and over again. And even if we do, we should take all the help we can get on the way. Time will always be limited, but this shouldn’t be an excuse for lousy security, horrible code or not doing that fantastic project that is brewing in our heads for months now.
Of course, not all of us can use all the shiny things everywhere. But we can use them as a starting point and start looking for other little helpers that will make us more effective. And we are not alone. We should show off our little time savers and speak about ways to improve within our networks.
Author: Holger Steinhauer
I am a passionate software developer with a DevOps mindset. I love all things Kotlin and have more than 15 years of experience in the market. Besides coding, I run the Virtual Kotlin User Group, co-organise the Kotlin User Group Berlin, started my own podcast Coding with Holger and founded the digital IT consultancy for the 21st century.