In a previous post, I mentioned that in order to have a successful DevOps experience, there were some key components and principles that need to be implemented. In this post, I’ll cover those components in more detail.
What I want to cover in this post is the experience that I had transitioning from a traditional development role to DevOps and what I learned to be useful in that transition. One of the nice things that I experienced with DevOps was that it pushes developers to take more ownership of their application because they are living through the pains and difficulties of running the application which in its turn pushes them to make running the app easier.
Wikipedia defines DevOps as:
DevOps (a clipped compound of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
I like to simplify this definition by saying that DevOps is when you’re not only responsible for developing the application but you’re also responsible for running and supporting the application in your testing and production environments. As opposed to the traditional way of developing where you have the luxury of developing the application then throw it over the wall to the Ops team.
During my career, I’ve worked at various organizations that had different stances toward open source frameworks and tools. Some of these organizations absolutely did not want anything open source near their code base. Others had a small set of “blessed” open source frameworks we were allowed to use. Some of the better places I’ve encountered, had a process for approving and documenting the use of new open source libraries in the code base.
The reason for this is that organizations tend to recognize that using an open source library comes with a certain amount of risk. Their goal is to manage the amount of risk they are taking on while developing software. The risk of using an open source library usually stems from the license of the library.
After years of being immersed in Java development, I must admit that I got spoiled by its strong and mature ecosystem. Hence, whenever I want to pick up a new technology or programming language the following must be there:
- Support by my favorite IDE (Eclipse or IntelliJ IDEA)
- Mature building framework. It does not have to be Maven or Gradle but it needs to be at least better than Ant.
- Easy TDD. This could be the trickiest one to achieve because not only do I need a testing framework, but it must also be supported by my IDE and build tool. Moreover, it must have an adequate mocking framework.
Groovy easily satisfies those criteria right out of the box. It has awesome support by IntelliJ IDEA, Gradle is written in Groovy and you can write JUnit 3-style unit tests.
Now we will cover the fun stuff for which we’ve been waiting. In this post, I’ll go over how to setup Sonar for a Java project that utilizes Ant for its build. I’ll go through the basic steps for installing and running a Sonar instance, and how to use a MySQL database for collecting metrics. Then I’ll go into some details around analyzing a Java project using Ant and Sonar. This involves writing Ant script, pointing to the source codes, analyzing the binaries, analyzing JUnit test cases, analyzing Ecl Emma coverage, etc.
What we covered so far ?
In my previous post I covered the reasons why software quality metrics should be collected and why improvements to the code should be made based on those metrics. In this post I’ll be illustrating how Sonar can fulfill the job of collecting metrics and driving decisions.
Sonar goes beyond just collecting and displaying metrics:
- Sonar can answer the following questions:
- What are our most critical code quality issues?
- Where is the highest concentration of code issues?
- How many working hours will it take to fix the issues?
- What does the metrics trend look like over the past year?
- Sonar can be used to track work tickets assigned to team members.
In short, Sonar helps us analyze the situation, take actions, and quantify the improvement.
I Love Dependency Injection But ….
I’ve burned myself so many times with dependency injection in the past. It make me nervous when I see a complex software product comprised of multiple projects and dozens of libraries without any comprehensive test that double checks the wiring. As our wiring grows and changes over time we need to continuously verify that everything works together. Dependency injection is one of the most valuable patterns in software development. Spring.NET is a necessity in today’s world and has great power that we need to harness in our products. With software products getting bigger and bigger, Spring.NET turns into a double edged sword that can hurt us especially if we cannot prove that every object is wired properly.
Beanoh.NET is a powerful tool for designing and maintaining Spring.NET configurations. One time I had an object named “messageSender” and that object controlled an HTTP connection to a web service by specifying a timeout for connecting and reading the HTTP stream. One day I needed to up the read timeout but for the life of me I couldn’t figure why the call was timing out after 15 seconds even though I’ve increased the timeout to 30 seconds. I spent hours looking into the documentation of the HTTP sender and debugged the code to no avail. In a moment of despair, I ran an Agent Ransack search through the whole web application package for the word “messageSender” and found two objects with that name one with 15 seconds timeout and the other with 30 seconds timeout. Each pulled from a different library. Wouldn’t it be awesome if my continuous build failed with a message saying “a duplicate object definition was found with the name of ‘messgeSender’. Are you sure you want them overriding each other ? ” If I was using Beanoh.NET it could have identified this duplicate bean.
What is Sonar and Why it’s Needed?
I was fortunate to be able to attend the 2011 edition of No Fluff Just Stuff . One of my favorite presentations was by Matthew McCullough on Sonar . Hence, when the issue of code metrics was raised at a client, Sonar seemed like the right tool to use.
Our client wanted to explore ways to measure and enforce software and code quality metrics. Their goals were to have quantitative measurements of their code quality and analyze those metrics to come up with a set of benchmark measurements. They wanted to utilize Sonar to discourage bad practices.