In The History of Failed Initiatives I mentioned that microservices as a concept existed for a long time. And yet, most of those who tried organizing their architecture around microservices failed or, to use different words, realized that benefits are shadowed by the increase in complexity (especially in operations). The spark that was born long ago became a star only recently. In order to understand why microservices became a hot topic not long ago, we need to understand better why they failed in the past. The explanation is simple. We neither had the tools nor understood the logic we had to apply. Do we have the tools today? Are we capable of putting in place the right procedures and have the mindset microservices require. I’d say yes, we have and we do. When I say we I mean people with the will and resources to make this happen. As in most other cases, once something new is proven and adopted by some, years need to pass until that something is applied by many. The good news is that I think that we are getting there and, slowly, the more conservative part of the industry (in other words, most of it) is starting to at least consider microservices as an option. Even Gartner had positive words for it. And when Gartner says jump, enterprise jumps. Continue reading →
This article tries to provide one possible way to set up the Continuous Integration, Delivery or Deployment pipeline. We’ll use Jenkins, Docker, Ansible and Vagrant to set up two servers. One will be used as a Jenkins server and the other one as an imitation of production servers. First one will checkout, test and build applications while perform deployment and post-deployment tests. Continue reading →
The previous article described several Continuous Deployment strategies. In this one we will attempt to provide one possible solution for reliable, fast and automatic continuous deployment with ability to test new releases before they become available to general users. If something goes wrong we should be able to rollback back easily. On top of that, we’ll try to accomplish zero-downtime. No matter how many times we deploy our applications, there should never be a single moment when they are not operational. Continue reading →
I’ve been working with BDD for years and felt that it needed an application that would facilitate the Behaviour-driven development work-flow. It would need to be made in a away that anyone can use it. By anyone I mean people with or without technical skills. Coders, testers, analysts, managers, business, etc. In that spirit, I started working on BDD Assistant. It is an open source application that can be used to create, manage and run BDD stories.
Now I feel that it is finally ready to go public. The application is far from being finished but there is enough done for the community to see what it’s all about. More information can be found in the BDD Assistant site. Latest release can be downloaded from our GitHub repo. Live demo (with some features disabled due to hosting limitations) can be seen from the BDD Assistant demo. Continue reading →
Behavior-Driven Development (BDD) is a process or it can be a tool. In many cases, BDD is both. However, it should not be a goal in itself. The goal of software development is to deliver quality as fast and as cheap as possible. The only real measure of quality is whether it fulfills user needs in a reliable manner. The best way we can take to accomplish that goal is through continuous integration, deployment and delivery. For the sake of this article I will ignore the differences between those three and refer to all of them as continuous integration or CI. Continue reading →
In the previous article we explored static analysis as one of the first steps in Continuous Delivery. Our journey will continue with unit tests.
Unit tests are probably the most important part of Continuous Delivery. While unit tests cannot substitute integration and functional tests, they are very easy to write and should be very fast to execute. As any other type of tests, each unit test should be independent of each other. What differentiates unit from other types of tests (integration, functional) is the scope. Each unit test should verify only a single unit of code (method, class, etc). Main benefit of unit tests are that they can find problems early due to their speed of execution. When ease of writing is combined with very short execution time it is no wonder that unit test often represent biggest part of automated tests. Continue reading →
The previous article CI Tools Setup ended with Jenkins up and running waiting for us to use it. Travis, on the other hand, was left aside and soon we’ll see why.
In this article we’ll explore static analysis as the first type of tasks that we should do in our delivery pipeline. Since that is our starting point, let’s go through the brief explanation. Continue reading →
We’ll continue where we left in Introduction to concepts and tools. The goal of this article is to set up a Jenkins server locally through automated and repeatable process with all the artifacts stored in the GIT repository. This will require tools like VirtualBox and Vagrant. It will also require registration to Docker. Unlike the previous article that provided only general information, in this one we’ll have to get our hands dirty and follow the examples.
What do we need in order to have a Jenkins server up and running locally? We need a virtual machine or available server, operating system installed and configured, Jenkins installed and configured. Since everything we do needs to be reliable and repeatable, we’ll also need a Version Control System. Examples in this article will use GitHub as VCS. Continue reading →
This is the first article of the Continuous Integration, Delivery and Deployment series. We’ll start out journey with brief explanation of Continuous Delivery. After short exploration of some of the tools used today, we’ll move towards the flow (from setting up brand new environment and getting the code from the repository to the creation of fully tested and verified distribution). Each section will present different approaches, compare different tools and, finally, provide some hand-on examples. After the flow, we’ll explore changes required in the development life cycle. Finally, we’ll dive into last steps required for the transition from Continuous Integration towards Continuous Delivery and Deployment.