In this post I want to talk a little about concurrency in the context of CQRS and event sourcing. Specifically, when a single aggregate is concurrently accessed by two commands (or command handlers, really). Read more
Requirements and applications evolve and change, leading to refactoring. For example, user registration now requires a first and last name, what was once an error may no longer be considered one, etc. In an event sourced application, that poses a few problems. In this post I’ll discuss a few strategies and my views on event versioning.
In that project we had some concurrency issues. One of those issues was that two events were applied on a single aggregate with an identical sequence number. The JGroupsConnector in Axon uses a consistent hashing algorithm to route commands. This ensures that commands with the same routing key will be sent to the same member, regardless of the sending member of that message. Within the project we used the aggregate identifier as the routing key, ensuring that commands for a single aggregate are processed in a single JVM, thus preventing duplicate sequence numbers.
To demonstrate such a setup, I’ve created a simple demo application, based on the latest version of Axon Framework (3.0-M3). Using Docker Compose, the application is launched twice (in two containers). The containers should then form a JGroups cluster, and handle a number of commands. Go check it out on GitHub!
I’m writing this post to contribute my take on the acronym CD, and the distinction (or perhaps, confusion) between the phrases Continuous Delivery and Continuous Deployment. These phrases are used interchangeably, and sometimes incorrectly, in various books, blogs and talks. And while these software engineering approaches (or disciplines) share a lot, there is one key difference.
Below are the slides of my talk “The road to continuous deployment: a case study”, as presented at the Dutch PHP Conference in June 2016. I’m planning to dedicate a series of blogposts to this particular topic later this year.
It’s a situation many of us are familiar with: a large legacy application, limited or no tests, slow & manual release process, low velocity, no confidence…. Oh, and management wants new features, fast.
But how to proceed? Using examples and lessons learned from a real-world case, I’ll show you how to strangle the legacy application with a modern service architecture and build a continuous deployment pipeline to deliver value from the first sprint. On the way, we take a look at testing strategies and various (possibly controversial!) tips and best practices.
(note: this post was first published on the blog of the Dutch Web Alliance)
Docker is currently one of the hottest technologies around, because it solves a very specific problem: the ability to easily package and deploy a (self contained) application, without the overhead of traditional virtualization solutions.
In this post you’ll learn how to build, run and host Docker containers, integrate with other containers, and see how Vagrant interacts with Docker.
I’m proud to announce that I’ve joined forces with a group of very talented web developers in the Netherlands and Belgium: the Dutch Web Alliance.
More information is available on our website, the full (dutch) press release is posted below:
APELDOORN: Freelance web developers bundelen krachten in de Dutch Web Alliance.
De Dutch Web Alliance (DWA) is een vereniging voor en door freelance
web developers uit Nederland en Belgie. Onze missie is om via kennisdeling, samenwerking en het combineren van resources, de positie van de freelancer en de kwaliteit van web professionals te verbeteren. Een lid van de DWA staat voor kennis en kunde op alle vlakken in web-ontwikkeling en kan zich als zodanig onderscheiden worden door klanten en opdrachtgevers.
De DWA richt zich niet op kwantiteit, maar op kwaliteit. Zo zijn het de leden onderling die bepalen of een nieuw lid ook daadwerkelijk kan toetreden tot de vereniging. Binnen de vereniging houden leden elkaar actief op de hoogte van alle laatste ontwikkelingen, bieden ze hulp en dienen ze als vraagbaak. Maar DWA leden springen ook graag bij andere leden in situaties zoals ziekte, deadlines, specifieke kennis. Zo krijgen afnemers van de DWA de flexibiliteit van freelancers, met de voordelen van full-service internet bureaus.
De DWA is meer dan alleen een keurmerk en kwaliteitswaarborg. Onze leden zijn voor het grootste deel actief in open source communities zoals PHP, dev/ops en system administration. Zij zijn dan ook vaak terug te vinden op nationale en internationale conferenties als spreker waarbij ze als experts en “leaders of the field”, andere ontwikkelaars helpen met nieuwe technieken, best practices en algemene kennis die is opgedaan uit de vele complexe projecten waar ze dagelijks aan werken. De DWA draagt hier nog een extra steentje aan bij door het organiseren van workshops en meetups voor niet alleen ontwikkelaars, maar ook leidinggevenden, project managers en CTO’s/CIO’s. Kortom: onze vereniging zet zich in voor een beter, professioneler en efficiënter klimaat binnen de web-ontwikkeling.
At my client Spotney, we have a pretty solid (and common) build infrastructure for our PHP projects; SVN commits are checked out by Jenkins, tests are run by PHPUnit, Sonar runs static code analysis, and artifacts are built and deployed to a staging environment by Phing. However, some of the code relies pretty heavily on (complex) db queries, adding the need for DbUnit style tests. The nature and quantity of the tests, combined with a slow VM (possibly related to this Xdebug issue) meant that our buildtimes were becoming prohibitively long.
Here’s how I did it.
Let’s assume we have a fairly standard Jenkins job. The job checks out an SVN repository, and periodically scans that repository for changes, triggering a new build if any are detected.
Each build of the job performs three steps:
- Run phpunit
- Run phing (target “build”)
- Invoke Sonar (using the Jenkins Sonar plugin – this plugin also allows invoking Sonar as a post-build action, but that option requires Maven)
After the build steps, the job publishes the test and code coverage reports, and archives the generated artifacts.
Disabling code coverage and Sonar for regular builds
Two of the most obvious optimizations (also suggested by Pascal) are disabling code coverage on all tests and disabling Sonar runs during regular Jenkins builds. We define regular as either manually started by a user, or by an SCM trigger.
Disabling code coverage generation in PHPUnit is easy, simply remove the “coverage-xxx” elements from the logging section of your phpunit.xml configuration file (see this section of the PHPUnit manual). Disabling Sonar is trivial too, just remove the last build step from the job.
However, this is not an ideal solution: we do want to generate code coverage information and run Sonar at some point, such as during nightly builds, preferably without cloning our existing job. This means that we’ll need to skip code coverage and Sonar invocations on all but the scheduled (nightly) builds.
The Sonar plugin supports excluding SCM triggered builds (“Skip if triggered by SCM Changes”), but that only works if you use the post-build action. Additionally, we need to be able to change the PHPUnit configuration – one file to enable code coverage generation, one file to disable it.
Conditional build steps
The Conditional BuildStep plugin wraps one or more build steps in a conditional execution block. One of the possible conditions is the build cause, i.e. was the build triggered by a user, an upstream project, a timer, an SCM change, etc. etc.
First we define the steps that should be taken for each nightly build of our job. These steps should only be executed when the build is trigger by a timer.
We add a “Conditional steps (multiple)” build step, setting the condition to “Build Cause” and the Build Cause to “TimerTrigger”.
Then we add our three (original) build steps:
As stated before, regular builds are those that are triggered by a user or an SCM change.
We again add a “Conditional steps (multiple)” build step. The condition for this step is a little more interesting, as seen below. We combine two Build Cause conditions (one set to “UserCause”, the other to “SCMTrigger”) using the Or condition.
We then add two build steps: the first will run PHPUnit without code coverage (note that we are specifying a different configuration file here), the second one will run Phing.
Note that in the above build steps we’re invoking Phing from the shell instead of using the Phing plugin. Unfortunately this plugin is currently not supported as a conditional build step (probably because of this JIRA issue).
As a final step we need to update our build schedule.
This will ensure our job runs somewhere after midnight (between 12:00 AM and 2:59 AM to be precise).
The end result:
- A nightly scheduled build, with all the bells and whistles enabled
- User and SCM triggered builds run (a lot) faster
Please let me know if you think this post is useful, or if you have any other Jenkins/PHP optimization tips!