We have created a process to upgrade our internal software that is running on a VM when a new build is produced.
We have two packages that we are using in our deployment. I will call them package A, and package B for simplicity.
Step 1: Deploy package A to server A. This causes an “Acquire Packages” step to be added before step 1 by Octopus which acquires package A and uploads it server A and then it acquires package B and uploads it to server B.
Step 5: Revert server B (VM) to a previous clean snapshot that doesn’t have our software before we deploy package B to server B.
Step 6: Deploy package B to server B.
Another “Acquire Packages” step is added before step 5. Nothing happens though, because Octopus says the packages have already been acquired and uploaded.
After step 6, we get a failure message because Octopus thinks that server B already has package B on it to deploy it from. It does not because we reverted it to the previous snapshot which does not have package B on it.
My question is: is there any way for us to force Octopus to make all servers re-acquire and re-upload the packages each time a deploy package step is called? Then after our VM is reverted back to snapshot, it would be able to re-acquire package B.
Thanks for getting in touch! Octopus assumes that it fully controls the deployment process and the restore process of the VM breaks that assumption. The only solution I can come up with is to split the project into two.
I might be able to recommend other approaches but I would need to learn a bit more about the problem you are trying to solve. Can you describe it a bit more for me? What is the reason why you deploy the same package B twice? What is the reason you perform the VM restore?
Thanks for the fast response! Basically we have a set of VMs that are being created using TeamCity and Powershell scripts. Each of these VMs has a role that corresponds to an Octopus role. We have a package (package A) that contains these roles for the VMs, so we deploy the package at the beginning to get the needed roles. Different tenants have a different subset of roles. We then have a step which waits for all VMs with the target roles from package A to come online. After all of this is when we check to see if the VM has a snapshot, and if it does we revert it.
Basically, we are reverting our VMs to clean snapshots so that we can install our new software on it.
For now, I moved the snapshot step to the beginning, but there is no way for us to know if all VMs have come online when this step is automatically performed by Octopus.
Hopefully I explained that a little better.
Sorry for the delay and thank you for providing more details. It looks like you have two logical steps in your deployment. First you setup your infrastructure (VM restore) and then you deploy your code.
Unfortunately, we don’t have an easy way to model this in Octopus right now but we are looking at ways to improve that in the future. Two projects is the best solution I can think of right now.
Please, let me know if there is anything else I can help with.
Thanks for the reply. That is correct - we have two logical steps. Create the infrastructure, and then deploy our code.
I am trying to do this with two Octopus projects now. I have the first project creating our VMs and running DSC to create our infrastructure. After the VMs are created and customized I added a step at the end of the first project from the “Deploy a Release” template and linked it to the second project which is going to deploy our code.
I am running into the same issue though when I add the “Deploy a Release” step, where Octopus wants to grab a package for that step that is in our second project. I don’t want it to grab that package or even care about it in the first project. I want the second project to handle all of that.
Am I doing something wrong? Or is there a way to do what I am trying to do?
This should work and I have checked it on the latest version of Octopus.
I will need a bit more information from you to get to the bottom of this problem.
Can you please provide:
- The version of Octopus you are on
The raw deployment log for both the parent (Infra) and child (Code) projects
The raw deployment process for both the parent (Infra) and child (Code) projects
- Can you insert Health Check step just before the
Deploy a release step and see if this helps.
Originally I was trying everything using TeamCity. After your response, I manually created an infrastructure release in Octopus and got it to work as you show in your screenshots.
When I try to deploy our infrastructure and code using TeamCity, it shows that "Requsted value ‘OctopusProject’ was not found’ for the “Deploy” project. This is where I was confused because I wasn’t sure why TeamCity/Octopus were trying to associate the deploy our code package in this step. Please see attached screenshot. Now if I can resolve this last part, I think I will have everything working as I want it to.
Sorry about the confusion…I have just started learning to use Octopus/TeamCity.
No worries. We are making progress and I think I have a solution to your last problem. More than likely you have to update your TeamCity plugin to the latest version. You can find more details about this problem here.
Please, let me know how you go.
That worked. Thank you Pawel! I think I have everything working now…thank you so much for your help, I appreciate it.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.