From Build to Run: Pointers on Secure Deployment

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.

person holding black fruit near cake for secure deployment analogy
You definitely want to protect this cake from malicious actors by ‘deploying it securely’ 🙂

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.

Read more →

Improving the quality of software delivery utilizing technology, process and people

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.

Read more →

Cypress – Don’t Let the Dialog Stop You

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.

Read more →

How to succeed at Progressive Delivery

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. 

Read more →

Quality pattern 2: Automate your acceptance tests

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.

Read more →

Multi products Scrum teams, how do you deal with that?

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 →

Why Integration Tests won’t save you… or your software

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 →

Going from a Value Stream Map to Value Stream Optimisation

Read this blog if you already have a Value Stream Map (VSM) and you are wondering how to reap its benefits using a structured process. If you need to know why and how you should make a VSM, please read the article ‘How to create a Value Stream Map’ written by my colleague Michiel Sens. Don’t forget to return here.

1. Read your VSM

So, how does a VSM look like? Depending on the linearity of a process people either display the process based on activities per role or by a flow of process steps.

Fig 1a. Process steps as a flow

VSM Linear process

Fig 1b. Activities per role
VSM activities per role

Even better is to combine the two approaches to get an idea of work per role as well as the overall process flow.
Read more →

Build and secure containers to support your CI/CD pipeline

There are 2 systems in any company that are critical: the payroll system, and the CI/CD system. Why? You may ask…
If the payroll system doesn’t work, people will leave the company and the company (may) face legal problems; the CI/CD system is the gateway to production. If it is down and there is a bug in production, it will affect your business; loss of revenue, loss of customers, loss of money, just to name a few.

Usually, I find these problems regarding the CI/CD tooling:

  • Poor Software Lifecycle Management, with outdated software, containing critical vulnerabilities
  • Ancient capabilities in the build agents. In extreme cases, frameworks and tools that are no longer supported by the vendors
  • Drifting agents. It means that teams had to do some sorcery to get the software build
  • Lack of proper isolation between different builds. It means that a build could access to another build files
  • Lead teams to upgrade or install a new framework
  • Outdated and strict rules mandated by a operations team. Usually from people that outdated heuristics on how software should be developed

Read more →