Just as Applications package together components. Releases package together Applications. This packaging enables you to release multiple applications together out to an environment. Applications dependencies are at a higher level than component to component dependencies. These dependencies are usually driven by changes in data structures, communication layers or by reusable components.

Everyone get up and move over…

Lets say that you have a reusable logging routine that has changed (backward compatibility broken) and multiple applications consume the reusable logging routine from a shared area. Each application should be re-released using the new logging routine. Release packaging in Release Engineer enables you to create a release with all of the applications that use the reusable logging component and then deploy the whole release to an environment, instead of deploying each application individually. Also, the release packaging shows at a quick glance which applications are going to be deployed. Everything is transparent so applications are not missed.

We have defined that components are made up of runnable binaries. And that components can depend upon each other. Applications depend upon components as well. You can think of components being the building blocks to making an application. It is a matter of packaging the right components together to make an application run and function. This packaging can include not only binary components, exes and dlls but also database components (table changes, indexes etc).

When you create an Application in Release Engineer, you are defining everything that that application needs to run, binaries, config files, properties, and database components. We then can deploy the application which in turn deploys all of the components that the application consumes. Release Engineer then drills down into the components and sends those binaries and database changes to the right servers.

Also, in Release Engineer you can have applications that need to released at the same time, but thats topic is for another post.

In our latest version of Release Engineer, we have included a built-in command line interpreter. This allows you to write portable, or platform independent, deployment flows. For example, your WebSphere deployment logic for a Windows Server can now be used for a Linux machine. No need to re-write the script that executes the detail logic of your deployment. This new feature is available via our download site at http://www.openmakesoftware.com/software-release-automation/

I view components as a set of binaries, .exes and .dlls or ,jars that make up a runnable part of an application. Components can consume other components. For example, the date time component can consume the logging component.

A well architected component will avoid circular component dependencies, even if the dependencies are removed by several layers. Circular component dependencies will cause headaches in the build and in the deployment process. Make a new component if you run into circular dependencies that way it can be reused correctly. You want see a component hierarchy that has all the relationships going in one direction.

In case you are not following the Harvest Community – I wanted to make you aware that registration is now OPEN for our CA AppDev Technical Conference.

This is a FREE Technical Seminar that will feature many of the CA AppDev products including CA Harvest SCM with Meister setup as a CI Server. Seating IS limited to please be sure to submit your registration form ASAP.

Registration information (including session agendas and recommended Hotels) can be found at the community: https://communities.ca.com/docs/DOC-231152533

In his presentation, Diego shared valuable information on modern application delivery trends and how they can be applied to the complex development challenges in regulated industries. He set the stage by stipulating that compliance and complexity represent a hurdle, but not a barrier, to successful agile development practices, and that such practices are becoming mission critical to enable innovation at ever accelerating speed across the board.

In fact, 2014 Forrester survey results shared by Diego substantiate that Agile methodology adoption is growing across engineering organizations worldwide, with 41.7% of 637 global software developers indicating that it is the “methodology that most closely reflects the development processes currently in use.”

Furthermore, according to the findings, DevOps or Agile all the way through is growing, resulting in the following top three benefits:
• One lifecycle and streamlined process, where everyone is involved in releasing business value
• Shared goals, where operations and development connected on business goals
• Tooling that integrates, representing huge opportunities for process automation.
You can learn all about Diego’s recommendations from the Polarion site

Continuous Delivery (CD) is a process, not a solution. Continuous Delivery is an extension of Continuous Integration. When a software update is saved to the version repository, the Continuous Integration workflow is triggered to execute steps that may include the calling of a script to compile code into binaries (Continuous Build), followed by a script to deliver the binaries to a list of servers (Continuous Delivery). In some cases where the production environment is made up of only a small set of servers, the Continuous Integration process may support production deployments, but in most organizations CI is used mainly by development and testing teams. When someone states they are doing Continuous Delivery, they are saying that they use their CI process to execute a deployment script.

Application Release Automation (ARA) is designed to fully orchestrate the delivery of software including infrastructure and database updates, server configuration management, calendaring, roll-forward, rollback, security access and component packaging. A Continuous Delivery process may call an ARA solution to perform the orchestration of the deployment, replacing the one-off deployment scripts written by developers.