| Author |
Message
|
| akil |
 Posted: Thu Nov 06, 2014 8:32 pm Post subject: IIB9: Shipping Integration Solutions |
 |
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
What's the recommended way to ship integration solutions to a client?
What we've been doing:
1. ship the bar file
2. ship a text file that hast the overrides listed
3. ship a readme.txt that describes the datasources, configurable services and user defined properties that need to be applied..
We usually face the following issues in this approach:
1. We require JDBCProviders to have a fixed name (because they are used in mapping nodes and these names are not configurable), but when there are name clashes (or ego clashes), we have to re-ship the code with the name required by the deployers.
2. Human errors in following the steps , such as forgetting to set the passwords for new datasources
Is there a better way to do this?
The examples that come with the toolkit, do some sort of script based installation, is that easy to do ?
_________________
Regards |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Thu Nov 06, 2014 11:33 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Assuming that you have no remote access to the client systems then you need to (IMHO)
1) Write a clear document (not a readme) with worked examples of what you are going to do. Screen captures etc. This also includes information on possible service interruptions (for a broker restart). Then the customer can schedule it to be done at an appropriate time. Include rollback instructions as well.
2) script everythnig. Don't leave it to the customer not to mess up a command like mqsicreateconfigurableservice
Don't forget to include making timestamped backups wherever possible.
3) make the scripts log everything to an installation log file.
4) Get the customer to send you the installation log after the application of your release (for validation and auditing purposes)
5) Make adding new Datasources a multi-step operation. Don't deploy anything to the broker that needs the DSN until it has been proved to work.
6) Ship a .zip (or .tar.gz) so all the customer has to do is unpack the archive and all the files in in the correct relative place for the scripts to run.
The steps outlined above also assumes that the customer does not use automated deplotment tools such as Puppet.
Obviously others who post on this forum will have different ideas. All I can say is that the steps I have outlined do work on several of our sires where we have no remote access whatsoever and getting to them physically would involve at least 10 hours on a plane.
But overall, do whatever suits you and your customer best. The more foolproof you can make it the better.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 07, 2014 5:45 am Post subject: Re: IIB9: Shipping Integration Solutions |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akil wrote: |
| The examples that come with the toolkit, do some sort of script based installation, is that easy to do ? |
It's easy enough to do script based installations, and easier using a framework such as ant to save you inventing wheels.
(Other frameworks are available and may or may not be better than ant in any given use case  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Nov 07, 2014 5:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The only thing I would add to the list smdavies99 has given is that the document in his #1 should - describe as much as possible what the solution actually does,
- where there are relevant points to add monitoring events as needed,
- whether the data being processed has any sensitive content that should not be captured for record/replay
|
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Nov 07, 2014 7:55 am Post subject: Re: IIB9: Shipping Integration Solutions |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
[quote="Vitor"]
| akil wrote: |
(Other frameworks are available and may or may not be better than ant in any given use case ) |
Always assuming that those frameworks are available on the target systems.
If you have a number of different customers and each use a different set of frameworks, it might be better to use the lowest common denomiantor available on all of them and that sould be shell scripting in say Bash/ksh/powershell etc.
It just depends...
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 07, 2014 8:37 am Post subject: Re: IIB9: Shipping Integration Solutions |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
Always assuming that those frameworks are available on the target systems.
If you have a number of different customers and each use a different set of frameworks, it might be better to use the lowest common denomiantor available on all of them and that sould be shell scripting in say Bash/ksh/powershell etc. |
Given how many people / Unixes use different shells, even that's not lowest common denominator.
It's not unreasonable to agree a framework with a client, especially if you can point to the benefits the client will get from using the delivery framework; the benefit can be and often is "the problems you currently have with delivery will go away"
| smdavies99 wrote: |
| It just depends... |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
