1

I am looking for alternative ways for developers to specify and maintain a list of files that need to be installed on the target system - to be communicated to the build team.

At my small company we currently have an Excel spreadsheet system - a certain template for each product has a list of files together with attributes like what directory to install to, whether an EXE needs to be registered as a service, preserve contents on upgrade, etc.... The build team uses this spreadsheet as the sole source of information for creating InstallShield builds.

Everyone seems to think the spreadsheet system is confusing. But no one has a better idea.

What do people do?

1

Personally I believe in the automate everything pattern, if you cannot automate it your doing it wrong. Using Excel sheets sounds like another piece in the process that could be prone to human error.

The installshield documentation talks about that you can automate, nearly everything:

InstallShield enables you to automate build processes through the automation interface without having to directly open the InstallShield interface and make changes in different views. By calling methods, setting properties, accessing collections, and so on, through the automation interface, you can open a project and modify its features and component data in many of the same ways that you would in the InstallShield interface. In addition, you can build a release using the Build method of the InstallShield automation interface.

This would mean the steps are all in code in the version control system, and not in loose documentation or Excel sheets. After updating the InstallShield project have the build system install the system and run some automated tests against it.

Maybe also read-up on DevOps practises: http://www.mobify.com/blog/devops-101-best-practices/

Hopefully the build team is inspired by the DevOps automate it all and they become your best friends in assisting getting everything up and running :)

| improve this answer | |
  • +1, as once you automated the process, you also documented it de facto : the script is the documentation. Even better : you put all datas in a configuration management system, both the deliverables, and the script(which will ideally link to a list of some kind of list of components) – gazzz0x2z Dec 8 '15 at 9:38
0

I'm working at QA for a SW shop and the situation is different as developers, here, are doing the packaging themselves.

Nevertheless, in your situation, I would ask them to provide a provisioning script (e.g. ansible script or any equivalent solution, puppet, chef, etc.) that is readable and executable (the main point) by your build teams to understand the targeted state.

From this, they can infer the proper InstallShield builds.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.