Many models and perspectives describe the complexity of an organization. In the end, it all boils down to people interacting with technology using processes. Sociologist Dr. Ron Westrum provided a typology of organizational cultures, including a generative type. Key characteristics for a generative culture include:

• Oriented to performance
• High cooperation
• Failure leads to inquiry
• Share risks

Encouraging these characteristics in the culture of an organization allows capacity, quality and innovation to grow. A CI/CD pipeline aids in facilitating the tools and processes to make these characteristics possible. A CI/CD pipeline is often perceived as a way to bundle and distribute software. It is the modern way to deploy software using automation instead of doing it manually. From a technical perspective, this is valid. Yet, the key concept of a CI/CD pipeline is to provide consistent quality and early feedback. By continuously monitoring the existing (quality) performance, you gain insights & data on how to improve deployments and the controls being applied.

Using the triad of people, process and technology, let us see what a CI/CD pipeline means for an organization and how it impacts the quality of the software delivery process.

Remember when we used to have a production, acceptance testing, integration and development version of a site? And that we struggled to get an extra environment from IT just so our customers could test our work?

Those days are over. Below I’ll show how to set up deploys for every branch. Or every commit. And how to have all of those versions available at the same time. The enabling technology is Netlify.

This post will show how to deploy a site on Netlify, based on a GitHub repository. And the killer feature: each single commit can be deployed to a unique URL with no extra effort at all. This facilitates fast and easy feedback from our clients on the products we build.

more…

Our experience with resources on secure deployment

Have you ever searched for resources on “Secure Software Deployment”? Most of the results revolve around the pentesting or putting security tools in your CI/CD pipeline. It would be the same as researching how to improve your cake baking skills, but end up with manuals of kitchen appliances. We want to address this gap: in this blog, we want to give you key pointers for a secure deployment.

So, what should you think of? We’ll start with a few aspects that we believe are important to think of when you work on a secure deployment. After that, we will touch upon the areas that you need to work on to actually achieve it. Finally, we’ll advise where to go from here.

Each organization involved in creating software eventually has a need to deliver that software. It is what we call the software delivery process. Typically, software delivery starts at the moment that a developer has written code locally and wants to publish it. Or, as Martin Fowler puts it: From the developer finishing the feature to getting that feature into production. At Qxperts, we have a more holistic view on software delivery.

Nowadays, Cypress is rapidly becoming the standard for UI test automation. With cross-browser support being available as per early June 2020, we at Xebia see the traction growing and growing. We’ve recently contributed to this growth by open sourcing a plugin that ensures that Cypress tests can deal with file download dialogs from the browser. In this blog, we explain the background and how we approached it.

Do you want to increase the quality and most likely the conversion rate of your web pages? In this blog post, I provide the steps on how to integrate Google Lighthouse into a CICD pipeline. Read on.

There is a lot of buzz around the practice of Progressive Delivery lately. Rightfully so, as it’s a great addition to continuous delivery. By gradually exposing new versions to a subset of users, you’re further mitigating risks. As usual with new and shiny things, many of us are eager to try it out, learn about the tools and shift to this way of working. But as is also common, there are reasons to do it, reasons to not do it, and reasons you might not succeed at it. Let me save you some trouble by elaborating on a few of them. 

Welcome to my second blog in the series of five quality patterns in Agile development that can help you to deliver the right software with great quality. In my previous blog, I’ve introduced Example Mapping as a method to get to specific examples for scenarios or rules that your user story is made up of. The output of the refinement sessions are your requirements and thus your tests. In this blog, we will take a further look at these test cases and why it is important to automate these acceptance tests. Not just from a development team perspective, but also what they can bring to your business.

Multi Products Scrum teams are in reality observed often. One team serving different stakeholders and customer segments. Both would like to use the same people to work on their improvements.

In most organizations there tend to be more products than teams. While scaling frameworks give solutions on how to cope with a big Product and orchestrating value delivery among multiple teams. But how to deal with many products and a few Scrum teams?

Read more →

Did the title tease you? Great, job is done! Today I will tell you my story about Integration Tests; it came after another knowledge share lunch with my pal Kenny.

By this definition an Integration Test is

(…) the phase in software testing in which individual software modules are combined and tested as a group. Integration testing is conducted to evaluate the compliance of a system or component with specified functional requirements. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready forsystem testing.

Sounds pretty waterfall, right? It is! also, the implementation approaches that I observed creates huge dependencies between teams, coupling the software release process.

Read more →