In order to analyze a problem when tests fail, we need to get into detective mode. The more evidence we have, the better. With enough differentiation, we can get a mental model of what works and what doesn’t, and better – where the problem might lurk, so we can go on and fix it.
TeamCity from JetBrains is an easy-to-use and powerful continuous integration system. It is a commercial product, but there is a special zero-cost license for small projects and FOSS applications. While installing TeamCity is relatively easy, its setup is further simplified via the use of Docker.
When writing unit tests we mostly focus on business correctness. We do our best to exercise happy path and all edge cases.
When most of us think of where the gravitational pull is in DevOps, places like San Francisco, New York, and Belgium spring to mind. But the Midwest? You bet, pardner! For episode 45, we take a field trip to Minneapolis for its first ever DevOps Days.
For some reason I needed extremely large, possibly even infinite InputStream that would simply return the same byte over and over.
Quite common real life problem. Simple map based configuration. How to handle gracefully a situation when a given key is not supported? See how Groovy can simplify the implementation.
Immutable components as part of your infrastructure are a way to reduce inconsistency in your infrastructure and improve the trust into your deployment process. Atomic deployments, combined with validation of the image and easy rollback, make managing your infrastructure a lot easier.
Why Ansible? It’s agentless. Unlike Puppet, Chef, Salt, etc.. Ansible operates only over SSH (or optionally ZeroMQ), so there’s none of that crap PKI that you have to deal with using Puppet. It’s self-documenting, with simple YAML files describing the playbooks and roles. It’s feature-rich.
A good clean application design requires discipline in keeping things DRY
Accuracy helps us fix problems quickly. But it’s definitely not so easy to come by, because it depends very much on the tested code. However, using the combination of the methods I suggested, and making use of working to test to refactor and simplifications, test accuracy is definitely within reach.
You have unexplained production issues from time to time. The business is impacted and the management briefs down your neck while the pieces of the puzzle are collected. There is no way to recreate this on QA set-up. The issue is lurking there for quite a while and becoming more and more frequent.
FX Playground is a JavaFX-based prototyping tool or live editor that eliminates the step of compiling Java code.
All these and many other characteristics can influence your component choices. And while your decisions will change over time, the more information you have readily available to you when making these choices, the better off you will be.
We were proud to host our 2nd DevOps State of the Union event June 24th. We held it in Santa Clara during Velocity. Wow! What an amazing group and discussion. The goal for the evening was to bring together some of the top thought leaders in DevOps, with the media and analyst community.
To reach 100% testing coverage is a dream for many teams. The metric used is code coverage for tests, but is that enough? Unfortunately not. Code line coverage is not the same as functional coverage. And it is full functional coverage that really matters in the end.
Make sure you didn't miss anything with this list of the Best of the Week in the DevOps Zone (July 11 to July 17). This week's topics include DevOps best practices and culture, Java debugging, code readability, test-driven development, Docker 1.1, and Docker's new ignore features.
Tests should run quickly. We’re talking hundreds and thousands in a matter of seconds. If they don’t we’ll need to do something about them. Quick feedback is not only an important agile property. It is essential for increasing velocity. If we don’t work at it, the entire safety net of our tests can come crashing down.
I had to create a Individual Development Plan (IDP) for me as part of the regular official procedures.
Introduce Factory or Builder instead of repetitive boiler-plate code when constructing key objects. Several benefits: makes it easy to refactor and evolve how underlying objects are stitched together, makes it easy to write more intention revealing code, and very relevant / convenient when writing automated tests.
For a preview of what will be covered in a future article, try changing stream() to parallelStream() in the example and see what happens. So that’s the basic operations we’ve covered so far in the blog. We can take a container make a stream, transform items, filter items, peek at them and do something with them.
According to Dr. Gary McGraw’s ground breaking work on software security, up to half of security mistakes are made in design rather than in coding. For the last 10 years we’ve been told that we are supposed to do this through threat modeling. What else can we do to include security in application design?
There is an easy way to define Docker container using Dockerfile. The other way to do it is private Docker registry. I will install now MongoDB in a Docker container w/o Dockerfile
This is the fourth in a series of posts on the new JBoss Red Deer automated test framework. This post describes features in Red Deer that make it easier to debug test failures.
Java 8 introduced the concept of collectors. Most of the time we barely use factory methods from Collectors class, e.g. collect(toList()), toSet() or maybe something more fancy like counting() or groupingBy().
We often forget the most of the value we get from tests come after we’ve written them. Sure, TDD helps design the code, but when everything works for the first time, our tests become the guardians of our code. Once in place, we can change the code, hopefully for the better, knowing that everything still works.