Hi there,
our company’s biggest Product Line consists of several products (.exe) that are built separately but released in one single Installshield/MSI package. Currently, one full build takes approx. 3 hours to complete, this is because all product builds are executed sequentially, obfuscated, packaged using Installshield. Considering we’re performing a lot of automated UI tests which take >8 hrs, one full cycle takes one working day, you can all imagine any errors that occur during builds/tests will slow down our delivery cycle.
This is one of the reasons we started using Continua CI. For this product line our challenge is designing the build/test/release process in such a way we can significantly decrease the build/test/release cycle. One of the objectives I think is breaking down the build in separate product builds with their own life cycle and once a product build succeeds, it should trigger an installer build which takes all completed product builds and then generates the installer. Does everybody agree on this strategy or any second thoughts?
Considering this strategy, we need a way to store our product builds (temporarily, or at least the last good build), since the installer build should retrieve those results and package this. What would be the recommended best practice? In our current (FinalBuilder 6/7) project, we would just copy all artifacts to a network location and then copy it back during the installer step. Copying files from/to network locations feels somewhat overrated and network performance and stability may impact build results is our experience so we’re looking for alternatives in the “Continua CI” philosophy. Options I can think of:
- Use build results/stored artifacts from Continua builds (configurations) -> haven’t seen this in the feature list, is this possible
- Store and retrieve packages using NuGet -> Is NuGet really meant to be used for complete product “exe/dll” releases?
- Use Octopus -> Encountered this in Continua Build Event Handler, have no experience on this, is this an option
- Keep using copying files from/to network location
- Other options?
Situations that may complicate things:
- branching: We still rely heavily on branches … main development = trunk, but we do almost have 1-2 feature branches alive, and 2 maintenance branches as well. Our builds should be triggered by commits in branches and trigger installer builds for those branches as well.
Does this make any sense to you all? Any suggestions are welcome.
Kind regards,
Remko Seelig
Hi Remko
You can use the build completed trigger to trigger a build when another completes, however this doesn’t scale very well when you have multiple projects all feeding into another. What you need is a feature we haven’t finished implementing yet, which is dependencies. I cannot provide an eta for the feature yet, but it is a high priority and something I would like to see completed in the next few months. This feature would allow you to chain builds so that project C can take the output from projects A & B, and control whether they are built fresh or use the latest available etc.
Nuget is not suited to storing artifacts, it’s really desgined for resolving compilation dependencies.
Octopus is designed for deploying complete applications (mostly web apps and services) to servers.
At this stage, your best option is to keep using the network location. We use branches and network locations ourselves, we prefix the folder names with the branch name and it works well.
Hi Vincent, thanks. This build chaining looks very interested. Once this is in beta or released I will definitely try it. We do have build that could benefit on this.
Side info: We’re looking for a next-step solution regarding artifacts repositories and dependency management. There are a lot of tools to look into which all have their pro’s and con’s. Our company imho has a little bit more complex environment than “average” projects; We’re not building website solutions or single product installers, but in fact have project containing a lot of products (in a single installer) which by themselves contain a lot of software, including embedded software, firmwares, etc. Our released product will be maintained for several years and we must be able to trace versions from installer to product, to embedded software, firmware and low level libraries and vice-versa. I’m not expecting a complete solution on this matter by Continua, but investigating how we can maximize Continua’s effectiveness together with tools that solve the artifact storage/dependency management.
We currently have a network storage that we use for product and component releases but as the complexity rises and the need to easily query dependencies, we need some tool support on this matter.
Anyway, thanks for your reply.