Thanks for getting in touch. Can you confirm I understand your situation correctly?
You deploy the same application package to 4 different countries
You want to deploy the same version to all 4 countries once that package is built
You use the same deployment process for all 4 countries, but spread across 4 projects
The way I normally model this situation is to:
Make each country its own Environment, for example Production-US, Production-UK etc
Make a single Project with the steps to deploy the Application
a. You will likely need to create variables scoped to each Environment/Country
b. You may want to create scoped steps to deal with variations between countries
Create a Lifecycle that promotes from Dev to Test and then to your Production Phase, which would contain your Production Environments, Production-US or Production-UK etc. This would allow you to test your application, and then deploy to any or all of your Production environments when you are ready
Now when you build your project in TFS, you can create a single Release in a single Project, and deploy it in a controlled way through to your different Environments/Countries without duplicating Projects.
Once you combine some of these Octopus concepts together you can create quite complex deployments, which can be much easier to manage over time.
Thanks for your help, eventually got my head around it and actually realized that the Octopus Create Release step was in fact just creating a new release for the specific project within octopus. Not actually creating the package as well.
So I basically just added 3 more Octopus Release steps with the associated projects, which is now working fine.
The other thing I did was add /p:OctoPackPackageVersion=$(Build.BuildNumber) to the build parameters of the VS Build step so that we actually are using the TFS build number.