Continuous Delivery - software-architectural topics

In my last post about Continuous Delivery was the focus on the delivery process. However in this post we will concentrate on the software and the necessary architectural requirements.

So the central question is, how to deliver new functionality as a software many times during a day without adverse effects. How is it possible that companies like Facebook despite major projects with hundreds of developers can manage this?

The first step in the praxis should be the system redesign from a monolithic application towards to split into small pieces (functions, components).
The components are separated and the communication is possible just via a clear API, like for example REST.


The second step would be the redesign of the underlying database. 
Encapsulating the access logic in an interface promotes a service oriented design. A distinction is made between an Application Database, belonging to one application, and Integration Database, shared by different applications and systems.


Avoid Server-side Session State
If short-time information are stored in a local cache of the server then we are talking about Server-side Session State and as such there are the particular instance fails the session is gone. For example during a deployment of new software version to this server instance.
Stateless services enable  a downtime-free deployments.

Keep backward Compatibility
This point is not so easy and it is very complicated to guaranty the compatibility after each modification of the system. Actually this means that the new functionality is co-exists with the old one.

Design for Failure
No system has got 100 percent availability. More important for the enduser is the impact of not functioning component. If one specific function fails, it should not cause the failure of the whole system. 
This is very crucial for continuous delivery concept, otherwise the risk of failure and its impact would be enormous.

Schema-less Database
Changes on the structure of database or its migration are in most of the time very complicated and risky.  The clear advantage is coming with NoSQL databases, or with migration running inside of the application and not in separated database migration scripts. Such scripts last too long and the migration would be not possible in the real-time.


Overall, the goal should be to reach the "Shared-Nothing" Architecture.  This architecture is defined through no direct references between two or many systems which enables a horizontal scalability and release deployment without down-time.

 
 

Read more

Continuous Delivery - process and requirements

The timely implementation and delivery are essential when it comes to achieving the real customer satisfaction in the software segment. The existing release models have proved in practice to be too inflexible and cannot meet these new requirements. The concept of Continuous Delivery should help to solve this problem.

Continuous Delivery begins where continuous integration stops. Now the software will not only continuously built and tested, but also delivered.
The idea of the faster software delivery has been originated by internet companies. There is the biggest pressure of course.

For platforms like Facebook, Etsy und Flickr is the Continuous Delivery the way how they work day by day, or better "hour by hour".

There are two very important requirements for establishing of Continuous Delivery.
As first a modern agile development process like Scrum is necessary. The close cooperation and bigger responsibility of every team member are the key reasons.
As second the Continuous Delivery Process builds upon an established Continuous Integration process.

The implementation of this concept requires radical re-thinking of the developers.
The focus in Continuous Integration is on the developers, however in Contionous Delivery the focus is on the customers, or the users.

Between a successful build and the availability for the customer is unfortunately a release.

The new standard is based on an technical abstraction called  Deployment Pipeline. The Deployment Pipeline defines so called stages with a different number of action in each stage.

The Build-Artifacts may be created just once! (see the yellow arrow in diagram)
It is very important to be sure, in each environment is the same binary on testing. I could tell you so many examples from the praxis, where this simple rule has been ignored and causes a lot of problems and errors in deployment process.

The created artifacts are stored in a repository and will be forwarded (installed) on each environment from this ("single") repository.

Often is the installation in the productive environment triggered manually, so called "sign-off".

Agile Manifesto:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

In this post are described the agile development process, automation and the requests connected with the organization.

But also the software product has to comply with certain requirements in respect of Continuous Delivery Standard. But about this in one of my next posts on this blog.

Read more