How to deploy multiple dependencies for a project?

Legacy Modelling
1

Hi there,

I have a question/scenario and looking for advice on how to approach this.

We have a “Project A” that requires MS C++ Packages in order to run. The problem is that it might need several of these packages (e.g. 2015 and 2017) and I can’t figure out a good approach of deploying several packages.

What I have tried currently is creating a Octopus project for VS C++ Packages. We’ve settled for a versioning like 2015.0.86 for a 2015 C++ package x86. Example:
image

That way we have a central storage for the dependencies and could potentially see where it was deployed to.

The idea was to use the “Deploy project” step within “Project A”'s process to also deploy the dependency to the C++ package. This way we would have both in Octopus and could manage it in one place. Example:

image
image.png1286×440 27.8 KB

The problem is that I have found no way of deploying multiple releases of the C++ project as a dependency, only the latest version which is not always enough.
Specific example of our use case:
“Project A” requires both 2015 and 2017 C++ packages. Within the C++ project in Octopus we have all versions from 2012 onwards. Within the step I could only deploy 2017, but not 2015 which will cause the deployment and startup of “Project A” to fail subsequently as the application wont start.

I assume that this approach isn’t the most elegant but I cannot think of a better one.

The baseline of my question is what approach would you choose for deploying several dependencies along with a single project.

My ideas would be:

  • include the dependency in each package of Project A. I find this not elegant as many other projects can have the same dependency, resulting in having hundreds of copies of a dependency in packages. Also it seems not transparent
  • Include a script step that just points to a defined location on the network and handles the logic (e.g. based of variables in Project A, knowing which dependencies to install)

None of them seem elegant, really. Do you have a best practice for this? I assume lots of people are facing the challenge of having many projects with identical dependencies.

Let me know if any of that is gibberish :slight_smile:

Thanks in advance,
Chris

2

Hi Chris

Thanks for getting in touch!

I got a couple suggestions for your scenario

  • Create a project for each version of the C++ package, use multiple Deploy a Release steps in you deployment process and get them reference the right projects as required.
  • Keep just 1 project with multiple releases for the C++ packages(your current settings), add multiple Deploy a Release steps that point to the same project, and specified the version when you are creating a release (as screenshot below)
    image
    image.png1309×530 52.8 KB

I would prefer option 1 as you wouldn’t have to specify the version everytime when creating a release.

I hope this helps!

Let me know what you think and how you go.

Regards
Eddy

1 Like
3

Hey Eddy,

great, thanks for the quick reply.

I’ve experiemented a bit and we are going the route of option 2. Even though it may seem tidious to specifiy the dependencies each release, they actually do change occasionally (e.g. the vendor updating from VS 2012 to 2017, thus requiring different packages). Also since there are so many C++ packages around (2012-2017, each in x64 and 86) having a project for each seems too much.

This seems to be elegant enough, I hope.
Again, thanks. You guys have great support, really appreciate it!

All the best,
Chris

4

Thanks a lot Chris and hope you enjoy using Octopus.

Should you have any more enquiry, please do not hesitate to contact us.

Regards
Eddy

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.