The Zend Blueprint for Continuous Delivery

The Zend Blueprint for Continuous Delivery

Continuous Delivery is a methodology, a mindset change and a leadership practice. When implemented correctly, it enables organizations to accelerate their time to market while maintaining flexibility, reducing risk and increasing application quality. Unfortunately, there is no off-the-shelf software that implements the full Continuous Delivery process of bringing applications from development to production. Much like traditional manufacturing, the delivery process has to be constructed from distinct stages which each require dedicated best-in-class approaches, and automation, with conveyor belts orchestrating connections between the stages to ensure the integration of the full assembly process. The Zend Blueprint for Continuous Delivery is a set of patterns for implementing best practices In one of the most comprehensive books that throughout each phase of the release cycle, while discusses Continuous Delivery concepts, authors Dave defining the relationships and connection points Farley and Jez Humble identify anti-patterns (common between each step and how the underlying practices that are highly ineffective). Notably, the first anti-pattern highlighted is manual software infrastructure should be constructed to deliver deployment, while the best practice and end goal optimal value, and achieve rapid application is complete deployment automation whereby the delivery. human performs just two simple actions select the version and environment and then press the deploy button [1].

The Continuous Delivery Lifecycle

Zend Technologies, Inc. www.zend.com

The Continuous Delivery Lifecycle

The model for Zends Blueprint for Continuous Delivery resulted from collaboration with enterprise application owners who recognize that reaching a higher maturity level in application delivery can make their organizations more efficient and significantly more valuable. Practical implementation concepts were gathered through the experiences of the Zend Professional Services team, which is responsible for implementing best practices with our clients, and has an understanding of how to build a roadmap for each step of the journey towards automation, consistency, and stronger DevOps collaboration. The value of establishing a Continuous Delivery practice has become more evident to software development organizations. However, while it often appears on the list of top corporate initiatives, actual implementation of its methodologies is still the privilege of a smaller subset of mostly advanced software development organizations. In fact, in a recent report, the IBM Institute for Business Value [2] found that only 21% of advanced organizations and 10% of intermediate organizations apply Continuous Delivery practices consistently.

Creating a reliable and repeatable process for releasing software can be achieved in phases, which helps reduce complexity and upfront investment of resources. Some areas will be simpler to automate than others. In addition, organizations will benefit by taking small steps toward Continuous Delivery even before the entire process is completely automated and the end-state is reached where production deployment is as simple as pressing a deploy button.

Zend Technologies, Inc. www.zend.com

Two Foundational Principles

The development organization must adopt the notion that the application is always production ready. Code in the main trunk has to consistently be in a production-ready state on every merged change. Achieving this level of maturity requires introducing agile development and release procedures, as well as rigorous testing very early in the development process, as soon as coding begins. This means that the deployment step is being refined and rehearsed over the entire development cycle, thus mitigating the risks of not being ready when its time to go live with the application. When code is always production-ready (which requires discipline through unit testing and agile practices on the developers side), the rest of the patterns or stages of the delivery cycle can be filled in over time to complete the Continuous Delivery workflow. The most effective workflow consists of sequential steps, separated by additional quality verification checks to ensure consistent and satisfactory product quality. One of the main concepts of a successful Continuous Delivery process is the understanding that a failure in any of the quality gates aborts the entire process, and when the problem is identified, it is immediately addressed.

Continuous Delivery Blueprint

Version Control Developers working in branches. Trigger CI when merging into main trunk. Continuous Integration Build Pull and organize application artifacts and dependencies. Code Quality Run unit tests and static code analysis tools to ensure code quality. Packaging Assemble application artifacts incl. dependencies & configuration into a deployable validated package. Infrastructure Automation Automated provisioning of infrastructure resources & platforms. Release Automation Automated application deployment across all runtime environments. Quality Control & Approvals Project specific functional testing & production sign-off. Application Management Provide instant feedback and diagnostics on deployed application to development and operations teams.

Zend Technologies, Inc. www.zend.com

Version Control and Code Management Policies

A fundamental requirement for automation in manufacturing plants is very strict inventory and supply chain management. The assembly line cannot function without a constant flow of the right quality-tested parts entering the factory doors. In software manufacturing, the inventory of code files, resources and other artifacts required to build the final product are stored and managed by a version control or configuration management system. The vast majority of mature software development organizations and virtually every organization attempting to implement a Continuous Delivery practice rely on a version control system to manage the flow of artifacts and keep a catalog of their versions and relationships. However its still possible to find software development teams who havent yet begun using source code version control. In the 2012 Zend Developer Pulse survey of over 2400 corporate developers [3], although 81% of development teams were already using version control, 19% had not yet implemented a version control system.

Version control is not an area that can be partially implemented or neglected. It is essential to have a clear versioning system for the artifacts going into the assembly line in order to assure that matching parts are fused together and the process can be reliably repeated while the changes occurring between executions are well organized and documented. Mature implementations of Continuous Delivery require all configuration elements such as third party components, as well as web server and operating system settings to be stored in version control together with the application code, tests and dependencies. It is recommended to store every possible artifact needed to build and provision the entire environment together with configurations that can potentially change over time. Although standardizing on a consistent application platform and a robust application packaging solution can ease this requirement, it is still mandatory to store at least the complete code base and artifacts needed to build and package the application.

Zend Technologies, Inc. www.zend.com

Continuous Integration
Continuous Integration (CI) is a methodology that evolved from extreme programming techniques based on the idea that developed applications should always remain in a working state and each break should be immediately fixed. With Continuous Integration, applications are built either at specific intervals, or in more conservative implementations, on every change checked in by the developers. The goal of Continuous Integration is to eliminate the traditionally lengthy and painful system integration phase, which often consumes much of the time of developers, testers and release managers who must patch code components together while clearing issues sequentially. The risk of conflicts can be reduced through frequent integration of the entire code base, starting from an early phase. Although it is possible to implement deployment automation without continuously integrating and frequently building the application, it is clear that CI increases productivity of the various teams by minimizing the integration phases. In addition, Continuous Integration is the process to ensure that the application is always in a working state and ready to be deployed with an assured level of quality provided by automated testing. Continuous Integration mandates the strict use of version control and places its trust in the developers discipline to ensure that changes are well-tested locally and merged into the main source trunk as frequently as possible, and that unit testing is an integral part of the process. In a test-driven development environment, tests are developed before or together with the applications business logic. This increases the reliability of a Continuous Integration practice as it allows unit testing of each piece of functionality in an automated fashion. Zend views the Continuous Integration process as a combination of three distinct phases - Build, Automated Testing and Packaging - executed sequentially with validation steps for added control over the deliverables and the quality of the manufactured application.

Commercial and open source CI solutions enable the orchestration of the CI pipeline, effectively managing and synchronizing the tasks required to build the application. Among the popular CI server choices in the PHP ecosystem are Jenkins, Hudson and Bamboo. They coordinate the Continuous Integration workflow and ensure an organized, repeatable build cycle rather than relying on manual scripts or a command line based process. The Continuous Integration server is integrated with the version control system and will automatically fetch source code and dependent artifacts to kick off a build cycle either on scheduled intervals (usually at least once per day), or as each new revision of a code file or other artifact is checked in to the main version control trunk.

Build
After pulling code and artifacts from the version control system, the Continuous Integration server launches the build process. For compiled languages, the build stage is more complex and follows a number of compilation steps, linkage, and building binaries or for some languages platform-specific executables. Most modern compilers feature the ability to compile and link code to executable binaries via command line, thus enabling automated builds. These are performed from either the CI server directly, or by calling a specialized build tool (generic or language-specific) such as Apache Ant, Gnu make, MSBuild or PHPs popular phing. PHP and similar dynamic languages benefit from a fairly straightforward build step since they do not require compilation and linkage. The result is fewer errors in the build stage. At the same time, more focus on automated testing helps to identify syntax

Zend Technologies, Inc. www.zend.com

and runtime issues early. As a dynamic, interpreted language, PHP generates code suited to multiple platforms because it eliminates the need to manage multiple flavors of binaries.

Automated Testing
When implementing a CI practice, it is necessary to enforce automated testing, which addresses both quality assurance of new functionality and regression protection. Automated testing that targets individual code segments on every change ensures that each component entering the assembly line is validated to an acceptable degree. Developers must create unit tests for each component being developed and keep tests updated in sync with requirements and code changes. The depth of testing within the CI process is fairly diverse. At the minimum, organizations should execute their suite of unit tests after pulling the latest version of the code and prior to building the application. More advanced quality controls also add a layer of static code analysis to ensure proper code styling, adherence to best practices, and further assurance that the code is both efficient and maintainable. These validation tests secure the fundamental operation of the new build. After build and packaging, the application is deployed to the test server. Continuous Delivery calls for another set of system-wide automated tests including end-to-end transaction execution. Such testing confirms the quality of the integrated assembled system as a whole and the success of the packaging stage as a result. Functional test and application-wide static code analysis allow the assembly line to provide a wider safety net for scenarios that go undetected by unit tests, and identify potential future issues resulting from poor coding. Organizations equipped to implement sophisticated test automation practices can run more advanced tests, simulating the production environment to test security, scalability and load, at the end of the CI phase. Because such testing at the CI phase often requires provisioning of complex testing environments, it is typically performed in a dedicated acceptance testing phase after the application is packaged and a proper acceptance testing or staging infrastructure has been provisioned. Basic tests for load and endurance scenarios during the CI phase do not replace the need for subsequent validation in a production-like or staging environment prior to pushing the application to production.

Packaging and Release Automation

Application packaging is an emerging discipline within the Continuous Integration process. This is partly due to the stronger association of deployment automation solutions with infrastructure automation, and partly because the need for app portability increases with cloud adoption. Deployment of a compiled or assembled build to testing and then to production environments can be achieved through a range of basic to advanced approaches. The first approach leverages distributed infrastructure automation tools designed to run scripts on remote systems based on centralized, server-driven instructions. The script (that needs to be written manually), copies the binaries, executable and configuration scripts, dependencies and resources needed to run the app from the build server to the target machine, and runs additional configuration scripts. A similar approach executes the script from a central location and performs deployment by remote login to the target machines sequentially, performing the same copy and configuration steps via the remote interfaces. The third approach takes advantage of package management solutions available in most operating systems, and allows the creation of deployable packages in either centralized repositories or portable files. The packaged repository or installer files are then run on each machine, typically via infrastructure automation agents. This requires platform-specific packaging efforts.

Zend Technologies, Inc. www.zend.com

 The most modern and comprehensive approach for packaging and release automation uses a dedicated packaging and deployment solution that is either infrastructure-agnostic or provided by the application platform. Use of such packaging and deployment solutions eliminates the dependency on specific infrastructures and their packaging formats, as well as infrastructure automation tools. The portable nature of these formats allows packaging to become an integral phase of the CI process. It is a common best practice to mimic the configuration of the expected production system as the default across testing and staging environments. However, business requirements may dictate a choice of production environments, which creates the need to either: (1). override a certain configuration when deploying on target production environments, or (2). support multiple production environments in parallel (e.g. diverse clouds and hybrid on-premise and cloud environments). In these scenarios, a comprehensive infrastructure-agnostic packaging solution alleviates the need to address different configurations at build time. The packaging solution can deliver a self-contained deployable format supporting deploy-time configuration adjustments based on parameters unique to the target environment type. The configuration of a specific production environment is then refined by the package installer, which can also enforce dependencies. Deploy-time configuration is crucial to automated deployment, extending flexibility to apps that rely on external dependencies and complex system configurations. An example of this scenario is third party dependencies such as payment gateways or central storage, which are not identical between testing and production. Deployment -time configuration scripts are commonly used in database and web server configurations or upgrades, and they allow the same package to be deployed on different web servers (i.e. Apache and Nginx), or different database setups (e.g. cloud database platforms). An application platform such as Zend Server, with its release automation and application monitoring capabilities, can be used to automate the process of creating and executing these scripts. This reduces the risk of configuration inconsistency across environments. Functional testing of the application should be performed until stable configurations are established across the multiple expected environments while application monitoring practices are implemented to detect errors in all actual target production environments. The Continuous Integration system pulls code from a version control repository, performs the builds (including dependencies), and creates an application package using the packaging system interfaces. Automating all steps, from fetching the code to providing a deployable package and performing them in every integration cycle, reduces the risk of a failed delivery. Following successful application packaging, the best practice is to deploy the application on a test server and immediately perform consistency and basic functionality checks to ensure the quality and functionality of the packaged application. This step, often referred to as a smoke test, validates application functionality in production. The complete, tested portable package is stored in the CI server or checked in the version control system to ensure consistency. Additional deployments of this specific build in testing, staging or target production environments should be performed using the same package. Just as it is ill-advised to dismantle and reassemble a vehicle once it moves off a manufacturing assembly line, the same principle holds true for an application once it has been tested and packaged. A release automation system that provides portable, reusable packaging followed by distribution to provisioned environments dramatically increases the efficiency of the Continuous Delivery process and gives businesses the flexibility to take advantage of diverse production targets. Continuous Delivery aims to keep software in a production-ready state so a package will be ready for deployment at any time to any environment. Use of release automation technologies is not as widespread as one might expect, but adoption is growing steadily. According to the 2012 Zend Developer Pulse survey [3], about 42% of developers at companies with more than 1000 employees and 38% in smaller companies practice some form of application deployment automation. Adoption of a packaging and release automation solution, whether a simple script-based solution or preferably a comprehensive, platform managed solution, is essential to achieve the production-ready state with each software build that constitutes a true Continuous Delivery practice.

Zend Technologies, Inc. www.zend.com

Another key element in a mature Continuous Delivery environment is the automated rollback mechanism. It serves as an insurance policy in cases of failed deployments in production. Several techniques can be used for rollback independently or combined. Traditional practice includes variations on building a parallel environment and swapping traffic at the load balancer, leaving the previous environment available for a certain period of time in case problems are detected and there is a need to revert back to the old environment. This practice is sometimes referred to as a blue-green deployment: the parallel blue production environment is ramped up and at the right moment switched to green meaning live production. Other techniques involve rolling upgrades where only part of the environment is upgraded at any given moment and the process can be stopped when problems are detected. Utilizing an application deployment management system that can deploy packages to production and support automatic rollback significantly reduces risk in the release process and promotes zero downtime deployments. Other benefits include suitability for very small software increments and lower cost of frequent releases. Rollback managed by a deployment system such as the one provided by Zend Server consumes fewer resources: deployments can be performed on the same machines while eliminating some of the potentially risky moving parts. Since updates and rollbacks may execute custom tasks (e.g. DB changes or data migrations), deployment and rollback should be thoroughly tested during acceptance testing.

Zend Technologies, Inc. www.zend.com

Infrastructure Automation
With Continuous Delivery, two layers of automation are required to fully provision and deploy an application: Release Automation and Infrastructure Automation. The Infrastructure Automation system focuses on automating the provisioning of runtime environments or platforms required to run an application, and gives the ability to provision virtual machines (generic and specially configured images) for the desired application runtime environment. This is usually done by adding an application server or runtime platform, a database or other application infrastructure elements. Traditionally, provisioning environments has been a manual, time-consuming and error-prone task that eats up valuable IT organization resources. Repetitious manual configuration of databases, application servers and web servers is a complex task that tends to create future problems of inconsistent implementations. Infrastructure Automation eliminates the manual labor associated with configuration of network elements, load balancers, user management, web and application servers, and databases. Infrastructure Automation is fundamental to cloud management systems. When combined with virtualization management subsystems, it paves the way for programmatically managed, on-demand infrastructure (Infrastructure-as-a-Service or IaaS). Add to this provisioning capability the application server and other middleware layers and you have a Platform-as-a-Service (PaaS) solution whereby the hardware, OS and runtime environment are completely virtualized and consumed on demand. Solutions for Infrastructure Automation include distributed agents on the servers, a centralized workflow management and rules processing engine, and scripting language support for orchestration of the production environment. These solutions can eliminate costs associated with manual provisioning and release steps. With automation, environments can be provisioned and launched at will, or terminated and discarded when obsolete. The process is faster and more reliable because manual intervention steps have been eliminated. The programmatic nature of such solutions ensures that environments are identical and always provisioned in the same manner and configured in the same way.

The Benefits of Environment Consistency

Staging and production environments are sometimes managed separately from the development environment. In many cases this includes application infrastructure elements such as application servers, databases and virtual machines that may not be configured identically by the same automation tool used in pre-production. Environment inconsistencies are a significant contributor to application release and maintenance costs. The 2013 Zend Developer Pulse survey [4] points to inconsistencies between development, testing and production environments as the major source of delays and failures when rolling out applications to production. While most applications can be executed on different runtime environments or application stacks, the result is tremendous effort invested in manually packaging, deploying and configuring the same application to target multiple environments. The same survey found that only 28% of over 2400 corporate developers utilizing PHP were standardizing on a single application stack across all development and production environments. A large percentage of application failures tend to occur shortly after deployment, and are attributed to inconsistent execution environments. One of the main Continuous Delivery anti-patterns pointed out by authors Dave Farley and Jez Humble [1] is the practice of deploying to a production-like environment only after development is complete, which is inefficient and costly. Using the same templates in provisioning test and production environments provides a higher level of assurance that the application will behave in a similar way throughout the release cycle. The level of assurance

10

Zend Technologies, Inc. www.zend.com

increases as the level of automation reaches the application stack and its configuration. Therefore standardization on an automatically provisioned application platform provides a higher level of confidence than OS-level standardization. Maintaining a consistent application stack allows organizations to eliminate environmental issues early in the development cycle and accelerate the developers problem resolution capability by taking environment variables out of the equation. It also allows developers to build the applications and troubleshoot incidents with a better understanding of the target production system. Many unexpected behaviors can be avoided by mandating a controlled, consistent application stack or platform. The fact that many application platforms are designed with portability in mind and supported by major cloud vendors allows organizations to use consistent application runtime stacks and be free to choose their production environments based on cost optimizations rather than specific technical characteristics.

Quality Control and Acceptance

Successful Continuous Delivery practices must have sufficient checkpoints throughout the automated workflow that can raise a flag and stop the process when something goes wrong. These big red buttons are spread along the assembly lines conveyor belt and pushed immediately when something does not look right. If a unit test fails, or static analysis identifies syntax or structure issues, or deployment to any environment is unsuccessful, or a manual acceptance test does not pass, then the factory must shut down until the problem is resolved. Developers, DevOps teams or sys admins must address the issue prior to continuing or re-launching the release cycle. IT leadership must instill in the organization a culture of quality as the first priority, and a sense of urgency to fix broken releases. Quality control and validation are fundamental requirements for automated software processes and, as in the industrial world, call for a combination of automated and manual validations. A number of automated quality control gates are typically executed during the Continuous Integration phase. Their purpose is primarily to ensure the functionality of the application building blocks, the adherence to best practices, and the basic validation of the deployable package. In reality, continuous and automated deployment to production only suits a small subset of software organizations that benefit from very frequent releases. The majority of software manufacturers deploy app packages to testing and staging environments for quality assurance prior to pushing the button and promoting these packages to production. Acceptance Testing is vital to the adoption of a dependable Continuous Delivery methodology. In this step, automated functional testing ensures the viability of business transactions executed by the application and user acceptance testing (UAT). UAT is typically executed by testers simulating a real users engagement with the application to validate its adherence to specifications and to capture defects missed by the automated testing scenarios. In addition to UAT, capacity and endurance testing ensure that the application can handle expected transaction loads, and perform over time without degradation of performance or availability. Load and endurance tests are automated and test scenarios are generated using dedicated tools. The testing environment must be provisioned to mimic production, as close as possible to an exact replica, in order to achieve the highest level of confidence in the application builds readiness for production launch.

11

Zend Technologies, Inc. www.zend.com

Application Management and Effective Problem Resolution

The DevOps movement emphasizes tight collaboration between developers and operations teams. Adoption of agile development practices requires feedback loops from testing, staging and production back to the developers, transforming the development process into one that is cyclical and iterative. Continuous Delivery involves a chain of feedback loops moving the application forward. Continuous Integration, Infrastructure Automation and Release Automation serve to automate the flow from development to production. However, other mechanisms must be implemented to complete the cycle, automating the reverse flow to allow intelligent escalation of problems from production back to development. In the escalation process, operations teams detect problems, isolate the responsible service and either resolve or escalate the problem to the developers when an application issue is identified. Operations teams require real-time visibility into both the applications behavior in production and the state of the underlying infrastructure. Application Management capabilities and shared visibility between development and operations for problem solving is an essential element of the feedback loop. However, despite widespread adoption of infrastructure monitoring; less than 25% of corporate development and DevOps teams are implementing any type of applicationlevel monitoring [3]. Infrastructure monitoring and management is an established practice for operations teams. Most operations teams deploy commercial or open source agent-based technologies to monitor infrastructure health via status reports, errors and health metrics in a centralized dashboard. While an infrastructure management strategy and escalation workflow is essential, it is limited to detection and resolution of primarily hardware and operating system failures. It does not provide drill-down and visibility into the applications behavior. This challenge can be addressed by providing developers and operations teams the visibility they need into both application and infrastructure issues. Best-of-breed application monitoring solutions capture applications execution data automatically, including issues at the code execution level. By proactively monitoring apps and making root cause analysis data available continuously, operations teams can detect application issues early and provide developers with intelligent escalation reports including the full context of the problem. The application monitoring systems can store incident data and execution history so all developers can access troubleshooting data and analyze historical trends without impacting production. Without detailed application behavior diagnostics, the majority of time spent on problem resolution is consumed in isolating and identifying root cause issues through reproductions, requiring attempts at simulation or recreation of issues, supported by the viewing of multiple logs. In this scenario, studies have shown that up to 80% of developers spend more than one-quarter of their time on problem resolution [4]. This is because software problems are often intermittent or random and difficult to reproduce, occurring only under certain capacity and usage conditions in production. Without continuous application monitoring, the challenge becomes one of pinpointing the source of the problem with insufficient application-level diagnostics data. A lack of visibility and automation in gathering and analyzing useful troubleshooting information at the application level can critically hinder the effectiveness of fast feedback loops.

12

Zend Technologies, Inc. www.zend.com

When Zend works with customers deploying the Zend Server application platform, we encourage their DevOps teams to leverage application monitoring and management capabilities early on. Starting in early development, and continuing throughout the app lifecycle including CI, automated test and User Acceptance Testing. In this way, developers not only can find problems earlier using more strict thresholds in pre-production and solidify the application, but also refine and set proper thresholds for monitoring rules packaged with the application and later deployed in production. Developers also become familiar with use of monitoring and root cause analysis tools early, well before critical issues find their way into the production environment. To support operations team requirements for centralized monitoring and improved problem detection and isolation, platforms such as Zend Server can forward application-level alerts to infrastructure management solutions such as Nagios and Tivoli. This gives operations staff greater visibility into the application environment so they can push intelligent escalations through the feedback loop.

Auditing and Change Management

Auditing and Change Management complement application monitoring by providing visibility into changes that occur in the environment over the lifetime of an application. When developers and operation teams are aware of changes in the environment and application settings, they can better understand what occurs when error events or performance threshold breaches appear on the dashboards. Deployments and runtime applications often fail because of changes in the production environment. Proper auditing at the application platform level, together with failure and performance metrics gathered by the monitoring solution, provide a clear, holistic picture of what changes were made in production and when, and what impact they had on app behavior and performance.

13

Zend Technologies, Inc. www.zend.com

Continuous Delivery Workflow - Putting it all Together

In a Continuous Delivery environment the source code flows from development to production through a software assembly line where a number of technologies help build, integrate, package and test the software while the application takes shape to become the final deliverable. The software moves through automated stages (and occasionally manual stages) to reach its final destination. There are many options for the technologies and software used to manage the process, and selection within them can be based on the preference of the developers and the operations team. These technologies that present a variety of options include the version control system, continuous integration platform, automated testing tools and infrastructure management system. Other tools along the assembly line are more platform-specific and may include a build tool, application runtime platform, application monitoring, and a release automation solution. An example of an effective Continuous Delivery process is a PHP application shepherded through the Continuous Delivery cycle and standardized on Zend Server as its application platform; using Jenkins as the CI server, git as the version control, phing for the build, and Nagios monitor production infrastructure. This example is based on a model successfully implemented with enterprise PHP development organizations and would flow as follows.

Continuous Delivery Process Example for an Enterprise PHP Application

1. Developers develop new code and run unit test on their machines 2. Developers check in their code which is then merged to the main trunk by the release manager 3. The Code Push triggers the CI process in the CI server 4. The CI sever triggers a build by calling a build target 5. The build tool assembles dependencies and creates the binaries 6. The build tool executes unit tests and static code analysis 7. The build tool or CI Sever pack age the binaries using the Zend Server SDK 8. The CI Sever launches a package deployment on a test server using the Zend Server SDK 9. CI S ever launches functional validation tests of the deployed application functionality and consistency 10. Zend Server application monitoring provides feedback on application and PHP errors during validation tests 11. The CI Server deploys the package to a testing Zend Server cluster 12. The CI Server launches a series of automated f u n c t i o n a l, l o a d a n d capacity tests 13. The Testers perform manual tests and complete the acceptance testing 14. The package is pushed to a production-like staging cluster for final verification testing 15. A production release is authorized 16. The package is pushed to a production cluster which was provisioned utilizing Zend Server provisioning patterns. The infrastructure is monitored with an infrastructure management tool with additional application-level events captured and integrated from Zend Server.

14

Zend Technologies, Inc. www.zend.com

Patterns and Best Practices

Zend offers a platform to enable Continuous Delivery (Zend Server), which provides consistency, automation and collaboration capabilities throughout the application delivery cycle.

Benefits Consistency
Zend Server provides the ability to ensure a consistent application stack and configurations across dev, test and production. This includes library management capabilities that ensure framework versions and other dependencies are correctly managed across environments. The configuration management capability of Zend Server ensures configuration consistency across clustered environments in dev, test and production, and alerts the team to prevent errors caused by configuration inconsistencies. This capability also enables an easy copy of settings from staging to production via an automated application deployment process.

Automation
With Zend Server, PHP applications can be automatically deployed from Continuous Integration into production through an automated packaging and release process. Zend Server provides a packaging and deployment capability for PHP applications that enables their automated deployment from dev to staging and from staging to production, which can be integrated with automated infrastructure deployment through automation software such as Chef or Puppet. It also provides automatic rollback capabilities that significantly reduce risk in the release process. Zend Server also enables automatic scaling and elasticity, by providing a capability to automatically provision identical configurations across a cluster or multiple cloud instances, and add fully-configured instances instantaneously when needed. Configurations can also be managed in an automated manner, where any missynchronizations (a common cause of production errors) are automatically corrected.

Collaboration
Zend Server equips dev and ops teams with shared visibility into an applications behavior, via a detailed set of application-level behavior diagnostics. These diagnostic and management capabilities include monitoring an applications performance and responsiveness, monitoring for critical errors, logging and managing changes to configurations, and providing code execution level visibility into application issues. User management capabilities allow easy access to information from both development and operations teams, but with different usage rights (developers cannot modify production settings but can see detailed diagnostic information).

Zend Server Patterns

A set of plug-ins and SDKs, made available as part of the Zend Blueprint for Continuous Delivery, help implement practices for automation, and enable the integration of Zend Server with popular Continuous Integration, Infrastructure Automation, and Monitoring platforms.

15

Zend Technologies, Inc. www.zend.com

Zend Blueprint for Continuous Delivery

CONTINUOUS INTEGRATION
provides Consistent PHP Stack Error Detection Library Packaging Application Packaging

RELEASE AUTOMATION
provides Automated Deployment Cluster Deployment Dependency Validation Automated Rollback Auto-deploy on Scale-up Library Versioning

INFRASTRUCTURE AUTOMATION
provides Automated Provisioning Automated Configuration Control Elastic Scaling

APPLICATION MANAGEMENT
provides Application Monitoring Performance Management Root Cause Analysis Change Tracking Shared Dev/Ops Visibility

Learn more, and see the latest list of Zend Patterns at www.zend.com/blueprint.

Summary
Businesses need agility to respond to ever-changing market demands and produce apps rapidly and with quality. Weve seen how agile development supports faster innovation. And yet the dynamic and unpredictable nature of modern production environments has created the need to pair agile development with agile application delivery faster software releases synchronized with business needs on a consistent basis. Continuous Delivery allows organizations to streamline and automate traditional app delivery processes that are manual, error-prone and costly in nature. The software manufacturing process is being transformed into an automated assembly line able to continuously iterate and deliver new code to production. Organizations are embracing DevOps and adopting Continuous Delivery to attain the goal of business agility and increased collaboration. We hope this paper has been helpful in outlining the steps and approach to implementing a professional Continuous Delivery platformone that solidifies the IT organizations position as a vital corporate asset in increasing the competitiveness of the company and quickly addressing the needs of the business.

16

Zend Technologies, Inc. www.zend.com

References and resources:

[1] [2] [3] [4] Jez Humble, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, http://jezhumble.net/ IBM Institute for Business Value, The software edge: How effective software development and delivery drives competitive advantage, http://public.dhe.ibm.com/common/ssi/ecm/en/gbe03545usen/GBE03545USEN.PDF Zend Developer Pulse, Summer 2012, http://static.zend.com/topics/zend-developer-pulse-survey-report-Q2-20120612-EN.pdf Zend Developer Pulse, 2013, http://static.zend.com/topics/Zend-Developer-Pulse-report-Q2-2013-0523-EN.pdf

About the Author

Ido Benmoshe is VP, Global Support & Services at Zend, responsible for professional services, PHP training and certification programs, technical support and solution consulting. The Zend Professional Services team leads implementations of agile methodologies, application design, optimization and continuous delivery solutions at global enterprises running mission-critical PHP applications. They focus on mentoring customers development and operations teams to deliver faster releases of high-quality PHP applications with higher performance and availability.

About Zend
Zend partners with businesses to rapidly deliver modern apps across web, mobile and cloud. We helped establish the PHP language, which today powers over 200 million applications and web sites. Our flagship offering, Zend Server, is the leading Application Platform for developing, deploying and managing business-critical applications in PHP. More than 40,000 companies rely on Zend solutions, including NYSE Euronext, BNP Paribas, Bell Helicopter, France Telecom and other leading brands worldwide.

Corporate Headquarters: Zend Technologies, Inc. 19200 Stevens Creek Blvd. Cupertino, CA 95014, USA Tel 1-408-253-8800 Fax 1-408-253-8801 Central Europe: (Germany, Austria, Switzerland) Zend Technologies GmbH, St.-Martin-Str. 53, 81669 Munich, Germany Tel +49-89-516199-0 Fax +49-89-516199-20 International: Zend Technologies Ltd. 12 Abba Hillel Street, Ramat Gan, Israel 52506 Tel 972-3-753-9500 Fax 972-3-613-9671 France: Zend Technologies SARL, 105 rue Anatole France, 92300 Levallois-Perret, France Tel +33-1-4855-0200 Fax +33-1-4812-3132 Italy: Zend Technologies, Largo Richini 6, 20122 Milano, Italy Tel +39-02-5821-5832 Fax +39-02-5821-5400 Ireland: Zend Technologies, The Digital Court, Rainsford Street, Dublin 8, Ireland Tel +353-1-6908019 2013 Zend Corporation. Zend and Zend Server are registered trademarks of Zend Technologies Ltd. All other trademarks are the property of their respective owners.
0106-M-WP-1013-R1-EN 17

www.zend.com
Zend Technologies, Inc. www.zend.com