When your IT organization consists of both developing software and managing the infrastructure behind it you might enter into a very interesting domain of managing the overall success and delivery of code and business functionality.
Currently there is a lot of attention on the SCRUM method which fills in the need for a better fit between the business functionality needs and software development. The method is incremental based and has an very elegant way of making the fit between chaos and order. It’s purpose is to deliver, big or small required functionalities in small steps frequently.
Now that also means that new functionalities and new code is delivered more frequently from the development factory, however that doesn’t mean that the operations organisation can deploy and integrate it at the same speed.
What is often seen is that when moving it into acceptance or production environments it delivers all kinds of problems in the context of configuration, integration, scalability requirements etc.
That is not really strange because with the increased pressure from agile development the flexibility that is needed can not be delivered by operations. The nature of operations is stability not hosting new code every 2 weeks. The nature delivers procedures, strict processes and operator mentality. That means the models for these two domains conflict by nature, and a big red wall forms between them. Culturally it could be perceived as the cowboys from development, and the others, the police from operations.
It could be the case that before you enter production you might want to do User Testing, Integration testing, Load Testing etc. For that you might need different environments and deployment and constraints become a hug issue. This because it is not only about the code anymore, it is about the setup of the whole infrastructure landscape. So it is about, software distribution, configuration of web servers, configuration of web services, setup of firewalls, setup of web service security etc. The use of SOA ￼will even make things more complex, because the small change of a service might impact other non changed parts of your environment.
Well although solving all these issues will cover many areas of the DevOps arena the Continuous * concepts focuses on the way to increase the agility of code delivery between the development and operations landscape. So what can the Continuous * concepts do for you?
Continuous Delivery/Deployment is based on the Agile Manifesto and it is meant to delivery code fast from the developers desk into your production landscape. It is focussed about building a stronger collaboration between software development and IT operations (DevOps), it focusses on processes, and high degree of automation for deploying, integrating and testing your code into a production stage. CD is taking the Continuous Integration concept further.
Continuous Integration is meant to integrate the whole development process where every change of code that is done by a developer will be compliled, unit tested, and will do a complete build of the application and even do tests on the application level. This will create a better application quality instead of developers working in isolation on certain parts of the code while the over all application breaks or doesn’t deliver the proper functionalities. In non CD environments it could take until a very late stage to find out that the combination of pieces don’t work together. It might take considerable time and resources to debug to the core of the problem in such case.
Both CD and CI concepts consists of ecosystems (process, automation, policies, etc) to support them.