5

The software product I work on has several services and user interfaces. There are separate setup files for each unit of the product for installation. We make customer specific changes and bug fixes every day. We need to store a seperate version for each customer.

Recently, we made the mistake of installing the wrong version of the product to several customers. We have a development team which uses github for version control and a technical service team, which installs the product and provides customer service.

I am a part of the developer team and we want our customer service team to have easy access to recent setups and customer specific setups. Currently, they ask the responsible developer for the setup files.

How can we organize and store our setup packages properly to avoid making mistakes?

Miguel van de Laar
  • 883
  • 8
  • 18
user2191454
  • 101
  • 6
  • 1
    See also: http://programmers.stackexchange.com/questions/187652/how-to-best-distribute-client-specific-configuration-settings – assylias Apr 06 '16 at 08:49

4 Answers4

2

Installations are easier to manage if you can automate them as much as possible. Instead of relying on some sort of organizational strategy to deploy different versions to specific customers, automate this process.

The programmers should build some sort app where a customer is selected and then their build identified and if possible, deployed.

I realize this is easier said than done. People are just going to make mistakes, so try and limit their involvment.

You could also include in the builds a certain client identifier in their app. Any update or installation would need to contain the same identifier or the update doesn't run. This could be as simple as a GUID in a text file on their system.

If you're doing so much updating on a regular basis for many clients, automation will give you a big advantage over your competition. This isn't easy, which is why many companies avoid client customizations if possible.

JeffO
  • 36,816
  • 2
  • 57
  • 124
2

I assume that you have a base product, with some customization.

A rollout for a specific customer would then be: pull base product from git pull and apply customization from git for the specified customer test in your test environment.

The above should all be automated, so once the test passes, push the install out to a server which your technical services team has access to. Have that server print any shipping labels or generate URLs for customer downloads. Now the technical services team just interacts with the server to select for a specific customer.

Now you have taken the biggest cause of mistakes, the hand-off between the developers and the service team.

user585123
  • 46
  • 1
1

Here is how I think of it, when it comes to software deployments.

  1. Application executables
  2. Structural Configuration and default settings
  3. Site Configuration
  4. User specific data

To my mind, only the application executables and and the structural configuration should be managed within the installer - which is then able to be deployed to all sites.

Sadly, Microsoft tend to encourage and/or force developers to mix these settings I to the same app.config or web.config file.

If you are providing software as a service to your customers, with separate installations, consider using puppet to manage your deployment and configuration settings.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
1

To make installers available to the customer services team:

A simple web page providing all the installers for them to download and pass on to customers.

To prevent customers installer another customer's application:

You could use a simple customer based key either to enter in the installer or in the start screen of the app. The key doesn't have to be complex, but just unique to each customer to act as a check to make sure they have got the right version.

keith
  • 119
  • 2