** Please note: The SDA Community Edition is no longer available. Please contact us by submitting your request on this web form. **
Like most jobs in life, preparation is the key to success. After getting to know the Serena Deployment Automation technology by working with the free version for a few hours (see yesterday’s post) I decided it was time to try for real.
My application was a Library Management System I developed a while ago for a public library in the United Kingdom. Like most developers I like to have something familiar to play with when I am learning a new technology.
So I started by defining my application to Serena Deployment Automation (SDA). The truth is that the help system (which is very helpful) suggested I defined the Components first. Partly because I like to try and test things to their limits and partly because I like to do the unexpected.
To start I clicked on Management, then Application and then Create New Application. I gave the application a name and a description and I was done. Easy. But was it too easy?
Once my application was created it dropped me into the Environment definition page. I was expecting this because I had been through the tutorials and samples when I first downloaded the Appliance. Here is where we define the target environments for the application. Every application lives somewhere. The environments are definitions of the locations you will be deploying to for development, testing and production. Each environment can comprise of one or more targets.
I clicked on Add Environment and the drop down menu invited me to pick from DEV, INT or QA. Well they didn’t suit me so I realized I needed to create my own Environments.
So now my plan was off track and that made this whole thing even more fun.
I clicked on Environments and there were DEV, INT and QA. So I clicked on Create Environment and all I had to do was to give the Environment a name and description. Next I was shown the Environment Details page. It had no details of course because it had just been created.
The Application was yet to be associated with the Environment and it had no resources. It was then it dawned on me. My application comprises of three parts. The database, running all the time, the programs running when invoked and the scripts that run once each time the application is refreshed. These resources, these components could go to any of the servers in my environment. I needed to define these components so I could tell SDA which components go where.
So I should have followed the instructions after all and defined the Components first. Good to know the help system has my best interests at heart. Even though I went down the wrong path all the entries I made are going to be used when we get down to the deployment itself.
So I now click on Components and the Create Component button.
Here I am invited, as usual, to give my Components a name and Description and, in addition, details of their location and the repository type. SDA supports almost 20 different types of repository including PVCS, Dimensions and Subversion.
My foundation is in place. Now I have to fill out a little more of the details and decide how the deployment should go. This whole process took no more than 5 minutes. In that time I had set up the Environments, the Application and the Components.
What I really want to do is deploy my Application and its Components through the sequence of Environments I have set up. To do that we need to define the process we want the deployment to follow. And that is what we’ll do tomorrow.
|Kevin Parker is a 30 year industry veteran, holder of three technology patents and is VP of Worldwide Marketing at Serena Software. He speaks and writes on application development methodologies, business analysis, quality assurance techniques, governance, open source issues, and tool interoperability, from the mainframe to distributed platforms to the web and mobile and embedded systems.|