I am trying to implement a standard deployment strategy within our organization. Prior to this, we were using the Import and Export facility to transfer jobs between environments. Someone mention the Server Manager and packages and some of the benefits it has. Initially I was all keen on using it until I started using. I found that it lacks some functionality that I need. Before reverting back to my initial deployment strategy I thought I would make a few inquiries about the tool. I read through the help text and was disappointed with what I found.
Here's my scenario; after the initial package is built and deployed to the next environment,
- if changes occur, I only want to update the changes in the next build. So I tried to bring the changes in only to be told the job already exist. You can't update the job, you must remove and bring it in.
- When I created Build 2 it recreates all the jobs and executable.
- When I deploy, I must overwrite the whole package. Seems excessive for a one job change
Am I missing something or is this tool just cumbersome. I would of thought that during deployment, only changed jobs would get updated. Does packaging flag what needs to be done during deployment.
Has someone used this tool and am I missing something. It seems to simple to me to be this complicated.
Thanks
InfoSphere Information Server Manager
Moderators: chulett, rschirm, roy
InfoSphere Information Server Manager
Jim Stewart
Hi Raftsman,
When creating a second build of a package containing 4 files with only one file changed you should receive three warnings telling you that job-designs are unchanged compared to last build. I've seen this behaviour today.
After deployment of this package: watch out for last-modification timestamps on the target-environment. For the three unchanged jobs the modification timestamp should remain unchanged.
Of course: you haven't got the option to specifically deploy just one job from a package like it was (and still is) possible with dsx-files. This is because it is assumed that a complete set of jobs contained in a package is approved for deployment to a production environment. Since it is impossible to approve deployment of just a part of the package, it is not allowed to deploy only part of it, either.
After using IISM for some while I really consider it quite a gain compared to the old transportation method. You have got far better knowledge which packages have been deployed by whom on which environment in IISM than with the old dsx-files, because you see the deployment history within the package.
Also, integration with subversion is excellent, and I would not want to miss it, now that we've got it.
When creating a second build of a package containing 4 files with only one file changed you should receive three warnings telling you that job-designs are unchanged compared to last build. I've seen this behaviour today.
After deployment of this package: watch out for last-modification timestamps on the target-environment. For the three unchanged jobs the modification timestamp should remain unchanged.
Of course: you haven't got the option to specifically deploy just one job from a package like it was (and still is) possible with dsx-files. This is because it is assumed that a complete set of jobs contained in a package is approved for deployment to a production environment. Since it is impossible to approve deployment of just a part of the package, it is not allowed to deploy only part of it, either.
After using IISM for some while I really consider it quite a gain compared to the old transportation method. You have got far better knowledge which packages have been deployed by whom on which environment in IISM than with the old dsx-files, because you see the deployment history within the package.
Also, integration with subversion is excellent, and I would not want to miss it, now that we've got it.
"It is not the lucky ones are grateful.
There are the grateful those are happy." Francis Bacon
There are the grateful those are happy." Francis Bacon
But if you have 1000 jobs and 1 changes. You have to deploy 1000 jobs. It is too bad the product doesn't't flag the change and deploy only the updated jobs. This make more sense. Last week. We deployed a whole system only to find out there were some minor issues . Instead of a 1 minute deployment, it took 30 minutes .
Thanks for the info
Thanks for the info
Jim Stewart
Why do You use a package containing 1000 jobs when you know that only one job changed since the last deployment?
Create a new package containing only this one job instead. Of course: this way you are documenting that there was a mistake in a job contained in the original deployment. But isn't this sensible?
Create a new package containing only this one job instead. Of course: this way you are documenting that there was a mistake in a job contained in the original deployment. But isn't this sensible?
"It is not the lucky ones are grateful.
There are the grateful those are happy." Francis Bacon
There are the grateful those are happy." Francis Bacon
True but if you have many subsequent changes to the initial package, you need to restore back to where you were when all was good. This could mean restore original and all subsequent deployments. We are using this deployment strategy between Dev and Test as well. Usually, the test phase uncovers many issues.
The purpose of this is to get to a state where the deployment package is bug free prior to getting to a production status.
I was thinking about this some more and it may be a matter of making smaller sub directories with fewer jobs. Not that I want to do this but it is a workaround.
The purpose of this is to get to a state where the deployment package is bug free prior to getting to a production status.
I was thinking about this some more and it may be a matter of making smaller sub directories with fewer jobs. Not that I want to do this but it is a workaround.
Jim Stewart