|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:||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.
|Door:||Marco Kroonwijk , 23-02-2015|
|Onderwerp:||Technical Coach Continuous Delivery CD Extreme Programming XP Agile Coach Technical Debt Architecture Development Team Role Craftsmanship Practices|
A while ago, I started working at Prowareness, and as new employees we choose our own role title best fitting our experience, skills, ambition and passion. I chose the title of Technical Agile Coach, without really having defined what it actually is. It just felt right!
However, occasionally, people ask me what a technical coach does and what the difference is with “other” Agile Coach titles. So here’s what that answer is, for me.
|Door:||Robert van Vark & Harm Pauw, 16-02-2015|
|Onderwerp:||Testing Tooling Continuous delivery CD|
This blog post is the first one in the series of “UI tests with Selenium”. This post will be about Selenium, how it’s often used and the problems that could arise when using it an a CI setup.
Selenium is one of the most used frameworks to create tests that interact with the browser. There are two flavors: Selenium IDE and Selenium WebDriver. The former is is not well suited for creating and maintaining test suites due to it’s record-and-playback setup: recorded tests are difficult to maintain and become outdated quickly. Selenium Webdriver provides a programmer with an API to interact with the browser in a uniform way. In combination with a test framework like jUnit, TestNG or Cucumber, a programmer can create UI tests in similar way as creating unit tests. Additionally, Selenium has features to record screenshots during the tests, which facilitates analyzing failures of your test runs.
|Door:||Prajeesh Prathap, 30-11-2014|
|Onderwerp:||PowerShell DSC Desired State Configuration CD|
In the configuration management life cycle in DSC, configuration delivery plays a major role. Once a configuration is authored, a delivery mode helps to enact the configuration on the target systems. These modes dictate how the configuration is enforced and corrected, as required. DSC supports two types of delivery modes: Push and Pull.
|Door:||Prajeesh Prathap, 29-09-2014|
|Onderwerp:||CD PowerShell TFS architecture|
Including Windows PowerShell script as part of your build and deployment process, brings you the flexibility of easily and effectively customize your packaging and deployment process. With the proper combination of environment configuration files (XML) and PowerShell scripts you can achieve the impossible. This post will show you how to run Windows PowerShell scripts remotely from a TFS build process.
Using CredSSP for second-hop remoting
One common issue with PowerShell remoting is the “double hop” problem. When the scripts are executed remotely on a Server A and then it tries to connect from Server A to Server B, the second connection fails to send the credentials to that server. As a result the second server fails to authenticate the request and rejects the connection. To get around this issue you need to use the CredSSP authentication mechanism in PowerShell.
|Door:||Prajeesh Prathap, 24-09-2014|
|Onderwerp:||Continous Delivery PowerShell CD TFS|
PowerShell is a powerful scripting language which can be used to customize the behavior of your package deployments. With PowerShell you can add powerful scripting to your build to for example execute a deployment process.
With TFS 2013 hooking up a PowerShell script in the build process is provided out of the box. There are pre- and post-build as well as pre- and post-test hooks. These make customizing build a whole lot easier.
|Door:||Prajeesh Prathap, 17-08-2014|
|Onderwerp:||Continuous delivery CD zero downtime deployment agile architecture|
Microsoft Application Request Routing (ARR) is a proxy-based routing module that forwards HTTP requests to application servers based on HTTP headers, server variables, and load balance algorithms. With ARR you can increase application availability and scalability by better utilization of content server resources with lower management cost by creating opportunities for shared hosting environments.
|Door:||Stephan van Rooden, 15-08-2014|
|Onderwerp:||agile Agile Coaches CD agilegames|
A few weeks ago at Prowareness HQ in Delft we had a very interesting discussion on how to add more fun to your work. Especially the things that are hard to do or are actually no fun to do at all. Very soon we were talking about gamification which is the use of game thinking and game mechanics in non-game contexts. And this triggered me to add some fun to a very large and important transition we are working on at one of our partners.
|Door:||Prajeesh Prathap, 27-07-2014|
|Onderwerp:||Continuous delivery CD zero downtime deployment agile architecture|
One of the main problems teams face when practicing continuous delivery is to manage zero downtime deployments to the production environments. The goal is to deploy as soon as possible and depending on the heartbeat of the organization, this becomes a higher priority to manage active users without losing their data and sessions during a deployment process. In this post I'll share some of the ideas and approaches that are been used for achieving the goal of zero downtime deployments.
An important process for reducing risks and managing a zero deployment downtime is by following the blue-green deployment technique. In a blue-green deployment scenario, the approach is to bring up a parallel green environment and once everything is tested and ready to go, you simply switch all the traffic to the green environment and leave the blue environment idle. This also helps in easy rollback and switch to the blue environment if anything goes wrong in the current installation.