So... what is DevOps?

In my last few posts I wrote about my experience in a DevOps role. It was not something to write home about, but it could definitely produce a few good diary entries, if that’s your sort of thing.

DevOps sounds like a great idea, just like Agile and NoSQL. There is no one thing that fits perfectly, if at all. That being said, they are great tools that are effective when used properly, just like any other tool. I’d like to list a few things that I think should be part of a defined DevOps job. I also don’t think DevOps should be a role on its own, which I’ll dive into after the list.

---

That’s right, there is no list. I love the idea that there should be someone that handles both development and operations tasks, but in reality it just causes knowledge to be stuck in the few people. I believe that this blog post describes it best - it’s not just simply described, but it’s also not totally the wild west. To paraphrase the article, DevOps can be thought of as an extension to Agile. That is to say we should be considering operational issues as part of a sprint, so that we allocate time to the team to update servers, script things that need scripting, and update infrastructure if it needs to be done. Most importantly is that these tasks must be taken on as a team.

As with anything I’m sure there will be people that disagree with these points, so whatever works for you and your team is the best choice. Having a dedicated DevOps person was not the best choice for my particular project but it might be for yours.

Basic Maven project setup

A basic Maven project consists of a project name, project id, and version.

<project>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>my-application</artifactId>
    <groupId>com.project.my-application</groupId>
    <version>0.0.1-SNAPSHOT</version>
</project>

From here, the structure of the source folders depends on the Maven plugins used to build the code. In most cases this will be Java code and following a generic main/test structure. Simply put all your code into the src folder and run mvn clean install to compile the code and place your JAR into the Maven repository (we’ll take a look at what this means in a later article).

If you look at the groupId above, you’ll notice that it looks like a package name in Java. This can match the package name but it doesn’t have to. In most cases a Java project will have multiple package names but only one groupId. Pick a groupId that uniquely identifies your project name. Similarly, the applicationId should identify your application within your project. The modelVersion tag is required by Maven, and is always set to 4.0.0.

There you have it! This basic Maven project builds a Java Archive that can run under a JVM.

JavaScript runner on Android

One thing that I’ve been searching for is a way to run a JavaScript application on Android. There are many JS applications out there but they are mostly just fancy text editors. Recently I found out that the AIDE project released a web IDE. It lets you create a JavaScript console application and runs right in the IDE. This is everything I wanted. I’m still playing around with it so I have yet to experience its full potential.

Much of the AIDE functionality has become subscription based or paid modules, so hopefully this module stays free.

https://play.google.com/store/apps/details?id=com.aide.web

What does it mean to be in DevOps?

One thing that has been surprising to me is that DevOps is just starting to be in the spotlight. Somehow the tasks that are now designated as "DevOps" were either not done in the past or never needed. In case one day you are asked to spend some time with DevOps tasks, I hope these pointers will help you get settled in.

Don't quit your day job

The January 2015 Tech Radar article from Thoughtworks ranks "DevOps as a separate role" as HOLD. This coincides with how I perceived the DevOps role. Depending on the project, there can be a large number of tasks assigned to DevOps. While it may be necessary to fully allocate a resource to complete these tasks, I strongly recommend against segregating the role from the rest of the development team. This is significant because the tasks that DevOps performs is intricately connected to the work of the development team. Separating the role from the team means that DevOps no longer has a stake in the work being done. By keeping DevOps within the team, the work will have much better coherence with the requirements of the entire team.

It's dangerous to go alone

The old man's wise words to Link are wise in many situations, and I can't think of any situation more fitting than starting the adventure in the land of DevOps. Similar to the Thoughtworks recommendation, DevOps should not be a separate entity but instead a role that is integral to the team. Although one or two developers can be chosen to take point on the tasks, the responsibilities should be approached as a team. It's in the best interests of everyone to provide feedback about the project's processes and workflow.

On the other hand, the DevOps lead should have the authority to make a decision on anything related. This doesn't mean that there is a conflict with Dev Lead priorities, but that DevOps should be the tiebreaking vote in situations of disagreement. Work needs to get done, and it's not the end of the world to make changes to the processes later.

Rome wasn't built in a day

...but DevOps work can sure sound like it should. All of the tasks are probably high priority, but they should not take priority over work that needs to be completed in your sprint. It may be difficult to factor this into your sprint velocity, but everyone must resist the urge to focus solely on completing the DevOps tasks. Break down the tasks so that they can be completed in one unit of work. If there is anything that is so important that it blocks development, recruit team members to help. After all if it's blocking development they have nothing to do anyway.

As I've mentioned before, it's important to have the entire team thinking about DevOps. The DevOps tasks will start to stack up if they aren't aligned to the project requirements. Don't alienate yourself from your team and don't allow your team to proceed without you. "Do it together".

Essential skills for a DevOps role

​Whether it's out of necessity or you're just plain nuts, one day you may find yourself in a DevOps role. Fear not, this is a quick list of skills you might find useful during your stint. If you're just plain nuts, I don't know how to help you, but read through this anyway.

Become a master builder

So maybe you're not the Lego master builder - you can still be the team's master CI builder. I didn't start out knowing everything about builds and I won't claim to be the best at it now either. Every project has different requirements but there should always be some generic workflow that drives a development cycle. With the basics out of the way start customizing things such as code scanning, reports, and other useful plugins.

Script it before you make it

Brush up on your shell scripting languages and it makes everything easier. I spent a lot of time trying to get Jenkins to do certain things. Most of the time there’s a plugin that does exactly what I want but most of the time it doesn’t work. With a scripting language such as PowerShell, you can automate many tasks in your continuous integration. A PowerShell script can also make your team’s lives easier by giving them a way to automate some boring tasks.

Don’t abuse the power though. Only write an external script to run tasks if they don’t fit into the build pipeline. You should be using the build tool to run tasks that are tied to the build pipeline.

Be one with the tool

There are so many ways to do things that it's easy to give up looking for a proper tool and rely on scripting. Once you find a tool that does what you need, spending some time to figure out its inner workings will save you a lot of time. As I mentioned in a previous post, you should try your best to accommodate to the way the tool wants to do it. When you push the boundaries of the tool you tend to get less return on productivity. Instead if the tool seems to lack in the functionality you want, you probably want to supplement it with another tool in the workflow or take a different approach to the problem.

There are many more skills that would be very useful in a DevOps role - this is just a tiny list of skills that could be the top three. In fact, I believe that every developer will find these skills useful and can contribute to a project through additional custom tooling and automation.

Best practices, and how to deal with them

Working on a Java project for the past year has taught me some things about projects in general. This point is important because I think we tend to become too comfortable with a single development stack and its set of best practices, that when we switch over to a different stack with different, or incomplete, best practices we get lost and do things in mysterious ways.

Be an expert in the field

Going into a new project with unfamiliar tools and libraries, you need to find out who is the expert or become the expert yourself. Justify your recommendations but be prepared to accomodate with your open mind. Regardless of the project timelines there is always a chance to change things up, especially for internal servers and applications.

Don't fight the system

Most tools have their own ways of doing things, so do it the way it wants to do it. On Ensemble, Faran spent the best years of his life trying to get it to do things in the way he thought was great (and to be fair it was a great way to do it). Unfortunately Maven thought otherwise and it gave him gray hairs that he has since dyed back to black. Once he discovered how Maven does things he easily got the projects set up and working as he had imagined it.

Get it right the first time

Easier said than done, especially when almost every technology choice is driven by the client. Even with this restraint, we should be able to make good choices about things such as project (code) structuring and team goals. Things like continuous integration and automatic deployments should be considered up front and made a part of everyone's responsibility, not just that of the DevOps representative.

Having been in a DevOps role for the first time in my career, I can say that it has been both the most interesting and frustrating role so far. It's surprising to me that this type of role is only starting to be developed now, after having so much time wasted communicating with an IT department that doesn't know exactly what a development team needs. I'm not saying that IT is incompetent (ours is great), but there can often be wildly different needs even between development teams within the same project. We should spend just a bit more time defining the DevOps role, and while not every project needs one, every developer team should go into a project with this mindset.

After all, more and more time is being spent configuring an existing system or application framework than coding one. Ensemble just happens to be an exception.