Chris also discusses how tech companies, specifically, can up their skills by learning improvisation basics, and how this all fits in with companies on their own DevOps transformation journey, plus illuminates some surprising facts about what the basics of improvisation are about!
I am a recent convert to thymeleaf for view templating in Spring based web applications, preferring it over jsp's.
Small debt to the quality may speed the development process, but it should be paid back, sometimes by means of complete revision of the technical solutions. In case, the debt is not paid back: product development is blocked by technical problems of the project.
Debates about the usefulness of ORM (Object-Relational Mapping) have been going on for the last decade.
In this article, I’m going to outline the importance or addressing your company’s source-control use before diving too far into CD. Specifically, I’m suggesting that you should decide whether your enterprise should do Trunk Based Development (TBD) in one big trunk or not.
In this episode, the Ship Crew discusses FlowCon with the brilliant Jez Humble and Gene Kim. What aspects of “flow” does your organization struggle with? Which people and departments in your software development process are that sad, soggy piece of lettuce? Join the discussion!
As applications that use Hibernate or any ORM frameworks grow complex, lots of performance issues don't get enough attention until it is too late. This article accounts for SLA time as part of the junits and allows developers to think in terms of calculating the number of calls hibernate is going to make in the background. This allows for developers to deal with facts rather than assumptions.
A few words about coping with complex flows (not the ones you would see in every demo app) and how to properly test them using thriving Mule testing framework - MUnit.
For a look at what's been happening outside of the DevOps Zone, we've assembled links from around the web, including a look at NGINX for web integration, release testing with CD, a Puppet change impact tool called Gonzo, Windows and Microsoft Azure updates from Chef and Puppet Labs, and more.
Make sure you didn't miss anything with this list of the Best of the Week in the DevOps Zone (Apr. 4 to Apr. 10). This week's topics include the Heartbleed SSL bug, Continuous Delivery vs. Continuous Integration, two very different introductions to continuous delivery, and perfect test automation.
The author was asked to put together examples how to mock Java constructs well know for their testability issues. He calls these techniques unusual mocking. Developers practicing TDD or BDD should be aware of testability problems behind these constructs and avoid them when designing tests and modules.
There is code in your application that you shouldn’t bother to write a test for.
If you do not know what A/B testing is about, take a quick look at the Wikipedia page on that subject. Long story short, the idea is to serve two different version of a page to your visitors and check which one is getting the most success. When you found which version is better, you can definitely switch to it.
Every now and then in the world of security, something rather serious happens and we all run around like headless chicken wondering what on earth it means. Did the NSA finally “get us”? Is SSL dead? Is the sky falling? Well it’s bad, but not for everyone and quite possibly not as bad as many are saying it is.
I'm not scared to talk about my vision of a perfect test automation in a context of a software development. My work experience gives me confidence in this question
Manual user management is painful. That’s why we focused one of the core foundational server management functions on automating user management. A key part of that pain relates to the manual interaction with your users.
This article describes how to publish JavaDoc API documentation for a Maven project built on Jenkins when that project is released. The JavaDoc API documentation is published using the same instance of Apache Tomcat 7 that Jenkins runs on.
This article, featured in DZone's upcoming 2014 Guide to Continuous Delivery (releasing April 14th), discusses the widely-discussed design practice of Continuous Delivery. But where did Continuous Delivery come from, what does it offer, and how does it work?
If you want to understand why I think CI and CD done correctly are almost the same thing, follow me down the rabbit hole.
In most real applications, there's no question the IDE "overhead" is well worth it. However, for the simplest of example applications, this is not always the case.
There's hidden costs when using complex frameworks, and you need to be careful how you set things up.
Continuous Delivery (CD) is a software development design practice used to increase the efficiency of the software delivery process. It encourages more frequent enhancements, and these smaller, iterative changes allow for quick bug fixes with minimal risk. Ultimately, CD is about keeping things moving.
I've grown weary of the blog posts and forum rants stating why one programming language is better than another.
I’ve been playing around creating new images and containers and debugging my Dockerfile, and I’ve wound up with lots of temporary containers and images. It’s really tedious repeatedly running ‘docker rm’ and ‘docker rmi’, so I’ve knocked up a couple of bash commands to bulk delete images and containers.