The essence of creating a pipeline is breaking up a single build process in smaller steps, each having its own responsibility. In this way faster and more specific feedback can be returned. Lets define a true pipeline as being a pipeline that is strictly associated with a single revision within a version control system. This makes sense as ideally we want the build server to return full and accurate feedback for each single revision.

As new revisions can be committed any time it is natural that multiple pipelines actually get executed next to each other. If needed it is even possible to allow concurrent executions of the same build step for different pipelines. However some measurements need to be taken in order to guarantee that all steps executed within one pipeline are actually based on the same revision.

Within a Jenkins build server instance it is possible to create a true pipeline for a Maven based project quite easily and in an efficient way. But in order to establish one we need some extra Jenkins plugins to be provisioned and configured properly as we will see below. Read more

Cloud computing is a model where the storage and computing capacity is provided as a service, usually on the internet, in a remote accessible fashion to heterogeneous parties.

The main drive to use cloud computing by these heterogeneous parties is cutting costs by the economy of scale and simplicity of maintainability. Maintainability is in essence the flexibility/changeability of a product/service during it’s life-cycle.

As a solution architect you are responsible to find the cheapest way to realize the current and possible future requirements of the business during the life-cycle of the product/service. Because cloud computing is about reducing costs, you should have a good look at it whether to use it or not.

The following part of this blog post describes several key choices to determine if and which cloud computing solution could be used for the product/service the company wants to provide. After the key choices, three cloud promises are described which have to be kept in mind while designing the product/service.

Choice between public/private cloud
Suppose a cloud (private or public) solution does not violates any of the corporate architectural principles, the following step in the investigation is to determine if a public or private cloud computing solution could fulfill the needs. The choice for private or public cloud will be mainly data security and privacy driven, like legal compliance, corporate principles, but also network latency and the available skills within the company to create and maintain a private cloud.

 Read more

At XebiaLabs, many of the questions we get about our enterprise deployment automation solution Deployit are from users looking for automated deployment as a prerequisite for Continuous Delivery. Often, this the result of initiatives to extend existing Continuous Integration tooling to support application deployments.

Increasing the frequency of whole-application testing, decreasing time-to-production and delivering greater business value faster and more regularly are goals we definitely share, and in this post we’d like to pass on some key experiences and lessons from working together with our users to help them realize Continuous Delivery.
 Read more

Part 2: Where is the employee formerly known as Architect?

The agile organization model

In the first blog post in this series Adriaan described a reference model for agile organizations. In other words: how an idea can be transformed into cash. An idea is prioritized together with all other ideas. It then gets planned, after which the idea is broken down into epics, user stories and tasks. At the end working software is deployed to production. In this process Product Owners play a key role. They coordinate the process to get ideas prioritized and user stories ready. Their main focus is business value. But, how about all those technical features and aspects? These technical features and aspects are the subject of this blog post.
 Read more

As explained in the previous blog, use-case slices are a great way of structuring your Product Backlog. This blog picks up where I previously left of by looking at a more concrete example. We will create the Product Backlog for a system for a library point-of-sales terminal.

 Read more

Putting software in production can be a challenge, often the frequency of going to production is low and the amount of changes/features involved is high. This usually results in a long and painfull deployment process. The release probably contains as many changes as possible because if you do not get your change/feature in this release the next release may very well be in 6 – 12 months.

To create the illusion of being able to prevent this and have more control the deployment department is often confronted with huge, 100+ pages, deployment guides decribing the deployment process in numerous, usual manual, steps. Incidents occur in the newly deployed software. Since there were so many changes in the new release, how are we going to find out which part of the newly deployed software is causing the problem.
 Read more