Third Party Development with CA Harvest

The Problem and CA Harvest

Understanding 3rd party development and CA Harvest

CA Harvest can be used to manage 3rd party developed software. I’ve had a number of clients ask my advice around how to manage development when a third party is involved in the development process. Defining, managing and enforcing a development process with a Software Configuration Management (SCM) tool is reasonably straightforward, but large organisations may depend upon third parties to provide software and system changes.
The following is a fairly common problem that highlights the complexity and potential points of failure when a customer has to interact with a third party responsible for any part of the software engineering process.
Third Party Development Complexity
The process can be summarised as follows:
  1. Change Initiator requests a system change by the supplier.
  2. Client Liaison gathers the requirements and initiates the development.
  3. The developer creates the necessary changes which, in this example, are delivered as any combination of the following:
    1. Step by Step Instructions to apply the changes,
    2. SQL to be applied, embedded within the email,
    3. SQL Packages to be applied to customer’s system, or
    4. A set of binaries to be copied to relevant system.
  4. Customer’s Test Manager co-ordinates the change (manually) and applies to in-house test rig.
  5. Changes are tested until accepted and promoted through the life cycle – using CA Harvest.
  6. Release Manager co-ordinates the deployment of the changes to the Production systems.
The major obstacle with this process is that whether the development best practice is linear development, agile, iterative or heavily prescribed, there are two parties with two sets of processes and tooling.
The process therefore becomes fragmented, error-prone, cumbersome and costly.

The Solution

The ideal solution for any organisation in a similar circumstance would be to extend their internal development processes and tooling to their supplier. This is easier said than done as it’s not very likely that both the customer and the supplier will be making use of the same tooling.
If we assume – for the sake of this Post – that the supplier is keen to please their customer then they might be willing to adopt the same tool as their customer – in this case, CA Harvest. If this is indeed the case then a quick and easy solution would be to provide the supplier’s developers with Harvest Clients and configure them to connect – via SSH – to the customer’s Harvest Server, where the source and binary code is managed.
Third Party Development: CA Harvest
Should the supplier find it impossible to make use of the same tooling then the only other [reasonable] alternative would be to automate the supplier’s updates to the Harvest repository by way of an automated event – after a check in to supplier’s Perforce repository, for example, then an event will fire to create the Harvest Package and check the relevant artifacts into ┬ásaid Package.

 

Leave a Reply

Your email address will not be published. Required fields are marked *