** Please note: The SDA Community Edition is no longer available. **
A couple of weeks ago I wrote about downloading the new Serena Deployment Automation Appliance. This is the free, community edition of the exceptionally advanced Deployment Automation technology we introduced last year.
The story so far
Since that post I have been working with the Appliance learning how to automate deployments. For about half an hour each day, for the past week, I have been pressing buttons, dragging and dropping and generally putting the technology through its paces partly to improve my understanding of how it all works but mostly to see just how much better automation is than the manual processes I used to use. I have to say I’m impressed! Let me take you on my journey and share with you how I became an automation-maven in just a week. In order to make this digestible I am going to write it in 5 separate postings.
Today, we have naming of parts* (Monday)
Serena Deployment Automation divides the aspects of deployment into 3 units of deployment:
- Applications – this is the entirety of what you are deploying. It might consist of scripts, executables, images, configurations, in fact anything you need to upgrade your application from its current state to its upgraded state.
- In my case my Application is the Llareggub (a fictional place in Wales) Public Library
- Components – these are the distinct collections of items, often from specific repositories Dimensions CM, PVCS/VM, VSS, Subversion etc), that are going to be deployed. Each collection will be of similar types of artifacts that need the same deployment process.
- In my case I had three collections of components: database schema changes in the /SQL folder, new programs in the /CBL folder and set up scripts in the /BMS folder.
- Environments – are where the deployments are going to to go from and to. These can be single or multiple deployment targets such as a single server or virtualized shopfront like Amazon.
- In my case I just followed the paradigm that was in use in the Appliance already of DEV, INT and QA, development, integration test and QA testing.
Each of these has associated attributes, the most important are:
- Processes – these are associated with Applications and Components. The component processes allow you to create activities that are different for different classes of components and to create different process for those components. For example a set of database DDL needs very different treatment to a bunch of DLL’s. But how we apply DDL to a MS/SQL server is very different to how we apply it to an IBM/UDB server. Imagine these as micro-processes, as your toolkit for deploying this kind of component. Application processes are macro processes made up of a collection of the micro-, the component-processes. Here you can create a deployment process that initially loads the application on to a new server or a process for putting out a security patch.
- In my case I had processes for deploying the application from DEV to INT and from INT to QA comprising of the stop-backup-apply-ddl-restart of the database, backup-deploy of the code and backup-deploy-execute of the scripts
- Properties – describe the nature of the Applications, Components and Environments. They specify, for example, the source repository type, the identity of a deployment target, the approvers and many other attributes.
- In my case I kept things simple and took defaults whenever I could.
Tomorrow – setting up the Application and the Components and a deeper dive into Properties and Processes. * apologies to Henry Reed, Naming of Parts and E. V. Milner, Baking of Tarts
