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.
Today's little-known git feature (or maybe everyone knows but me? I only found this a few months ago) is for quickly switching between branches. Usually I would switch branches with: git checkout [branchname]
This is the third blog in a series that's loosely looking at tracking application errors. In this series I’m writing a lightweight, but industrial strength, application that periodically scans application log files, looking for errors and, if any are found, generates and publishes a report.
The DevOps security story is deceptively simple. It’s based on a few fundamental, straight forward ideas and practices:
In Grails we can execute code when the application starts and stops. We just have to write our code in grails-app/conf/BootStrap.groovy.
Do you know the feeling when you discover a bug in a functionality that was working couple of weeks (or versions) ago?
Every week here and in our newsletter, we feature a new developer/blogger from the DZone community to catch up and find out what he or she is working on now and what's coming next. This week we're talking to Troy Hunt, Software Architect and Microsoft MVP for Developer Security.
Moving toward Continuous Delivery can be a big change. Ideally, releases speed up and smaller, iterative changes allow for quick fixes and less risk. But any team undergoing changes will experience growing pains. Let us know with a comment: What has your experience with Continuous Delivery been like?