|Door:||Barry Overeem, 25-03-2015|
However, my intention with this post wasn't starting an in-depth discussing about the misuse of Scrum. It's the questions Mike presents to assess the quality of an organization's way of working that triggered me.
|Door:||Harm Pauw, 24-03-2015|
|Onderwerp:||Continuous delivery CD Testing Tooling|
This blog post is the third blog post about UI test with Selenium. In the previous blog, we looked at Selenium Grid and how it can help you in executing browser tests using real browsers. Unfortunately, running a Selenium Grid also has some downsides, like the need for quite some infrastructure and maintenance. In this blog, we'll take a look at Docker and see how we can use it to overcome some of these downsides.
|Door:||Marco Kroonwijk, 24-03-2015|
|Onderwerp:||CD Continuous delivery Prowareness|
At the beginning of 2015 we had a great session with a lot of Prowareness customer representatives, in which we asked them to provide feedback on our past performance and future plans. One of the topics being discussed was the introduction of Continuous Delivery (CD) in their organization. Most surprisingly, many customers asked us why they should start with it, because that was not such an obvious thing to them. We got signals that we had overrated the familiarity with, and awareness of, the benefits of CD. This was worth exploring further.
|Door:||Barry Overeem, 23-03-2015|
Within companies that use Scrum properly the organization is built around fixed, cross-functional, self-organizing teams who are given the freedom and responsibility to think of a strategy they believe will result in the best product. Everyone around the development team is focused on supporting and facilitating the teams in building the desired product. In consultation with the Product Owner, the development team themself decides what to work on and how much they can handle during a sprint. This results in a clear focus and the opportunity to obtain a sustainable pace of continuous delivery.
So far so good.
The fact is that a large part of nowadays organizations consists of contractors. They have got a core of employees, and around it a flexible layer of contractors they can easily up- or downscale. In this turbulent age with rapid changing business- and market conditions, organizations are almost obliged to have this flexibility. Next to this, an increasing amount of people with specific knowledge and skills also choose to be independent. They are not willing to work for companies for years in a row but want the freedom to switch assignments and engage in new challenges and environments continuously.
As mentioned before, Scrum is based on fixed, cross-functional, self-organizing teams. The best teams have a stable composition for a longer period and hereby have the opportunity to really become a strong team instead of a group of individuals. They've experienced ups & downs together and thoroughly know each other’s qualities and personality. But how do you build such a strong team, when a large part of the team consists of contractors? Is it actually possible to build a true team when contractors are part of it?
|Door:||Maarten Kossen, 23-03-2015|
|Onderwerp:||Continuous delivery Practices Tooling|
In this series of blog posts I will share my favorite Continuous Delivery tools with you. For each of these tools I will highlight why it is useful and in which part of the Continuous Delivery chain it can be used. During this series I will cover the following tools:
Managing a single server is quite easy. You just install the software you need and configure it as you see fit, no harm done and not a pain to maintain. When adding a second server to your setup you get a little challenge. You want it to be identical to the first server and you start copy-pasting config files around after having installed the same software. Then you add the third server...
As you may notice, the above solution doesn't scale well (among some other issues). It especially doesn't scale well in a business or an enterprise environment where you don't just have "a server" or "a configuration" but you have multiple clusters or servers each with their own configuration. Managing, and keeping homogenous, multiple database servers (for example) can become a tedious task. For these situations, you need a tool to work with all these servers. Not only to set them up (install software and apply a configuration), but also to update them (both software updates and configuration updates) as well as keeping them homogenous (ensuring they all have identical software installed and an identical configuration).
Luckily, there are solutions for this problem. I'm going to show you my favorite one in this blog post: Ansible.
|Door:||Harm Pauw, 12-03-2015|
This blog post is a little bit different than a usual one. Instead of discussing a particular topic, I’d like to share the location of a open source project we’ve been working on. The details of this project will be presented during the CD Market of Prowareness.
In the last couple of months, we worked on a solution to make it easy to run Selenium tests using real browsers without having to configure a complete Selenium Grid from the ground up. The solution uses Docker to create an on-demand Selenium Grid each time Jenkins triggers a new build. After the job completes, it automatically stops and discards the Grid.
The Jenkins Plugin and Docker images are hosted on Github and Docker Hub:
This is of course still work in progress, so let us know what you think and try to regularly take a look at new versions!
|Door:||Harm Pauw & Robert van Vark, 04-03-2015|
|Onderwerp:||Continuous delivery CD CI Tooling Testing|
This blog post is the second one in the series of “UI tests with Selenium and more”. This post will be about Selenium Grid, how it’s often used to test with multiple browsers and the challenges you face with supporting infrastructure.
In the previous blog we discussed Selenium WebDriver, why people often use it in combination with HtmlUnit instead of real browsers, and why it is not that smart to use HtmlUnit only. In case you’ve forgotten: none of your real customers actually uses HtmlUnit, as it doesn’t have a GUI. Also, it is not possible to take screenshots since there’s no rendered page to capture.
The main reason for teams to use HtmlUnit is that it can run easily on your headless build server. Also, it would be very time-consuming to manually create individual suites of automated tests for every OS / browser combination that your customers use. Fortunately, Selenium provides a framework of doing exactly that: Selenium Grid. With Selenium Grid, you can set up a grid of multiple browsers and OS combinations that you can use in your tests. What makes it better is that your tests can be completely browser and OS agnostic. This enables you to use the same test suite to test multiple browser and OS combinations.
Selenium Grid’s architecture consists of several Nodes and one central Hub. A Node can provide one or more browsers, e.g. Chrome and Internet Explorer, on a specific operating system. The Grid is controlled from a central place called the Hub.
Running your automated tests only requires that you create a RemoteWebdriver object, provide it with your wishes regarding the browser and OS and point it to the URL of the Hub. The Hub takes care of distributing your tests to a node that satisfies the browser/OS combination you requested. You can also specify the number of concurrent browser instances on each node, so that you can run your tests in parallel. There’s also a web based Console that - although it’s a little bit primitive - allows you to see the status of each node.
If you only want to test using one particular browser, it’s not necessary to have a separate Hub and Node. In this case, you can start a Standalone server which acts like both a Hub and Node. You can use it in exactly the same way as a grid with a hub and multiple nodes.
You’ll need some infrastructure to create a grid: either in the form of physical servers or virtual machines running on a server on-premise or in the cloud. The setup and maintenance of this grid costs effort and money, even if it’s only used for short periods. For this reason, companies often let multiple applications use the same grid: that way the grid is used more efficiently.
However, sharing a grid with multiple applications also has some downsides. Often the usage of a grid is not evenly distributed so during “rush hours” you can have a queue of tests that wait until they can be executed. This could lead to long execution times and false positives due to timeouts. Also, if the tests of one application are taking a long time to run or even hang (caused by timeouts or other problems), they could seriously affect tests from other applications.
An ideal solution for these problems is to have a completely new and fresh grid every time you start a new test run. This way, test runs for different applications don’t interfere with each other and when a test run goes bad, subsequent test runs are not affected by it. But booting physical and even virtual machines takes up quite some time, so this is not very practical.
In the next blog post we’ll take a look at Docker and see how we can apply this tool to provision on-demand Selenium Grids while avoiding long startup times and other problems.