Octopus Deploys Old version of DLL

eric_adjei-boampong · 22 September 2014 19:31

Hi All,

I’m experiencing a problem with Octopus during the deployment process. I have about 20 projects in both TeamCity and Octopus Deploy using the same template for build and deploy activities.

All projects build and deploy successfully without any issues except one project, eg. (A). We’ve made changes to a DLL file by adding another class file. When this builds in TeamCity or locally, the DLL is updated as usual, BUT when Octopus deploys this package, the new updates added are removed.

Another project, (B) depends on this DLL in project A, so once (A) is built, (B) starts building but (B) gives an error due to the fact that it can not find the new changes which was added in project (A). Project (B) builds successfully when I manually copy the DLL from the NuGet package or from my local machine in the TeamCity build stage.

Initially, I thought it was a TeamCity issue so I added a new configuration step to take care of the deployment process. This didn’t fix the problem.

From a lot of troubleshooting in TeamCity I’m confident the Octopus deployment process for some reason removes the changes or picks whatever version it likes for deployment. The weird thing is all the projects are configured exactly the same but this is the only one with this issue.

Any help will be very much appreciated.

Vanessa_Love · 23 September 2014 02:36

Hi Eric,

Thanks for getting in touch! There are a couple of places this might be failing, and without specific error messages we will have to try to troubleshoot this.
Octopus itself takes a package and deploys it. It doesn’t really decide to make changes or not, it just dumps the package contents.

So a few questions.

Can you confirm that the package that is built for Project A contains the updated DLL
Can you confirm the package is immediately available when TC triggers the deployment?
Could we get a screenshot of both the package in your repository that is created, and the project step that identifies that package.
Are you creating a new release each time the package is updated?

Thanks!
Vanessa

eric_adjei-boampong · 23 September 2014 15:32

Hi Vanessa,

Thanks for the quick response. Answers to your questions below.

  The package created in Project A has the updated DLL

  Yes, the package is available immediately for deployment because there’s a separate configuration step to allow TeamCity to finish the build before it gets deployed. Like I said, this is the ONLY project which acts this way.

  This is the package that is created after the build. (I’ve tested and confirmed this has the latest changes by copying it manually and using it to build Project B

[cid:image001.png@01CFD71A.C8615FE0]

This is a snap shot of Octopus settings

[cid:image002.jpg@01CFD71C.5FC2C5D0]

I’ve tried the different options above and still same results.

This is a snap shot of the Process Step Details

[cid:image003.jpg@01CFD71C.5FC2C5D0]

  Yes, a new release is always created after each build.

Please let me know if you have more questions.

Thanks,

Eric.

Vanessa_Love · 25 September 2014 06:44

Hi Eric,

I think we are getting some where. When you say (I’ve tested and confirmed this has the latest changes by copying it manually and using it to build Project B and (B) starts building but (B) gives an error due to the fact that it can not find the new changes
How and where is Project B building?
Are you getting this error when B builds?
When you say coping it manually, where are you copying it to?
Octopus doesn’t Build anything, so we are wondering if the dependencies for the build are correctly configured.

Vanessa

eric_adjei-boampong · 10 February 2015 22:01

Hi Vanessa/Damian,

I have this a build from TeamCity which I need to deploy. When I create my build, it generates a nuget package which Octopus deploys without any problem. Now I also have an artifact which carries information about the build which needs to be deployed as well. Screen shot below explains this. Is there any way I can have octopus pick this Artifact up during the deployment of the package? Any links to a similar scenario would be very much appreciated.

[cid:image003.png@01D04550.AB8BF200]

Thanks,

Eric

Damian_Maclennan · 11 February 2015 06:25

Hi Eric

There isn’t a great way to do that unfortunately, Octopus really wants things in a Nuget package. Do you need this file deployed in the same place as your nuget or somewhere else ?

You could package it up in it’s own package, deploy it to a custom install path then use a powershell script to copy it into the other path.

Or you could use the API to push the contents into the release notes for the release, then write that out into your install directory.

Both solutions are a little ugly though, can you tell me a little more about what’s in the file and why it’s deployed ?

Regards

Damian

eric_adjei-boampong · 11 February 2015 15:21

This file has to be deployed into the same location as the package. This file has the build information like the build date and time, build number and changeset number etc. How do I use API to push the contents to a release note?

Any links to where I can find this?

Thanks.

Damian_Maclennan · 11 February 2015 23:11

Hi Eric

If you create a release from our TeamCity plugin it uses Octo.exe under the hood. You could instead write a powershell script that called octo.exe directly and piped in the contents of your file, some doco is here http://docs.octopusdeploy.com/display/OD/Creating+releases

However, the way most people do this is to use team city to stamp this metadata into the assemblyinfo.cs so it’s compiled into the binaries. There’s some documentation here https://confluence.jetbrains.com/display/TCD8/AssemblyInfo+Patcher

I would look into that as an option, it’s a much more standard way of achieving this sort of thing.

Regards

Damian

eric_adjei-boampong · 12 February 2015 16:03

Thanks Damian.

I figured it out in a different way. I simply added an empty .txt file into my source and added a command line step in TeamCity to write the build info to the file after the build before packaging it for deployment. It works like magic and will like to share with other users who have the same issue.

I can share my solution online with the community if there’s a link to the problem.

Thanks,

Eric.

eric_adjei-boampong · 18 February 2015 22:15

Hi Support,

I have an issue here and can’t find answers online.

Scenario 1:

Deployment to DEV is very Successful without any problems. I deploy to 2 different machines with different Roles. This works perfectly in Dev environment. Please see the UI output

[cid:image005.png@01D04B9C.2D190460]

As you can see, Step 1: (Only deploys this file to a shared server which sits on say server A).
Step -5: (Deploys the same package to different folders on the same machine say server B) …This works perfectly in the Dev environment.

Scenario 2: Please bear in mind, I don’t have to deploy into any any shared Location as shown above in Step 1 in the snapshot above.

When I try to move this to TEST, it gives me a preview of steps 2-5 which makes perfect sense(Because like I explained above, I don’t have that corresponding machine in TEST because we don’t need it) and it also shows the name of the Machine I’m trying to deploy to. When I click deploy to Test, nothing happens. NO DEPLOYMENT TO TEST HAPPENS BUT status says BUILD SUCCEED. Why? It says Success but the Raw log says “Pending”. Please is there any way I can get past this so I
Could this to TEST?

[cid:image004.jpg@01D04B9E.6D3992B0] [cid:image007.jpg@01D04B9E.6D3992B0] [cid:image012.jpg@01D04B9E.6D3992B0]

Thanks,

Eric Adjei-Boampong, PSM 1, ITIL, CCNA

[psm1_badge]
[Description: incomm-logo]
Software Build Engineer

11900 Biscayne Blvd, Suite 400
Miami, FL. 33181

Tel: 305-381-7729 Ext. 504

eric_adjei-boampong · 19 February 2015 16:19

Thanks very much Vanessa. My set up was it to deploy in parallel. So I reversed that and did a rolling deployment. I will update my Octopus version to the latest and try deploying in parallel to see if that will work.

Thanks very much.

Eric.

From: support=octopusdeploy.com@uservoice.com [mailto:support=octopusdeploy.com@uservoice.com] On Behalf Of Vanessa Love
Sent: Thursday, February 19, 2015 7:12 AM
To: Eric Adjei-Boampong
Cc: tender2+d17bdc1d1711265d7027f71ad9380f62a5b49b691@tenderapp.com
Subject: Re: No Deployment in TEST Environment but “SUCCESS” IN OCTOPUS

Hi Eric,

Thanks for getting in touch! That is really weird, thanks for all the screenshots. It does appear that all of your scoping is corect because you are seeing deployable machines which you have shown. I am wondering if a bug has been introduced, but to figure it out I need to ask some questions. I am making a guess what might be going on here, so please bare with me.

How is your process for this project setup? Do you have any of your steps set up to run in parallel? We did have a few bugs with steps and running in parallel. I also can’t tell what version you are running - the steps in parallel was modified and fixed the bugs we knew about in 2.6.2.
A full deployment log might also help (but maybe not if it is that issue).

Let me know what you find.

Warm Regards,

Vanessa Love
Octopus Deploy

On February 18, 2015 at 2:15 PM Eric Adjei-Boampong <Eric.Adjei-Boampong@qpaynet.com mailto:Eric.Adjei-Boampong@qpaynet.com> wrote:

Hi Support,

I have an issue here and can’t find answers online.

Scenario 1:

Deployment to DEV is very Successful without any problems. I deploy to 2 different machines with different Roles. This works perfectly in Dev environment. Please see the UI output

[cid:image005.png@01D04B9C.2D190460mailto:image005.png@01D04B9C.2D190460]

As you can see, Step 1: (Only deploys this file to a shared server which sits on say server A).
Step -5: (Deploys the same package to different folders on the same machine say server B) …This works perfectly in the Dev environment.

Scenario 2: Please bear in mind, I don’t have to deploy into any any shared Location as shown above in Step 1 in the snapshot above.

When I try to move this to TEST, it gives me a preview of steps 2-5 which makes perfect sense(Because like I explained above, I don’t have that corresponding machine in TEST because we don’t need it) and it also shows the name of the Machine I’m trying to deploy to. When I click deploy to Test, nothing happens. NO DEPLOYMENT TO TEST HAPPENS BUT status says BUILD SUCCEED. Why? It says Success but the Raw log says “Pending”. Please is there any way I can get past this so I
Could this to TEST?

[cid:image004.jpg@01D04B9E.6D3992B0mailto:image004.jpg@01D04B9E.6D3992B0] [cid:image007.jpg@01D04B9E.6D3992B0mailto:image007.jpg@01D04B9E.6D3992B0] [cid:image012.jpg@01D04B9E.6D3992B0mailto:image012.jpg@01D04B9E.6D3992B0]

Thanks,

Eric Adjei-Boampong, PSM 1, ITIL, CCNA

[psm1_badge]
[Description: incomm-logo]
Software Build Engineer

11900 Biscayne Blvd, Suite 400
Miami, FL. 33181

Tel: 305-381-7729 Ext. 504

Aditya · 27 June 2016 10:27

Hi our project uses different libraries. is there a way so that if there is update required for only one dll and i can do that update without deploying the whole project.

Daniel_Fischer · 28 June 2016 05:15

Hi Aditya,

Thanks for getting in touch! We do not support partial deployments of single files. Octopus believes that previous versions should always be available for use, which is why we follow the versioning strategy that we do.

However by default Octopus uses Delta compression to calculate the difference in the packages and only copy the data that was changed to the Tentacle. (NuGet packages only)
As an example, if you were to change a single DLL in a package and then try deploying it, Octopus will only need to copy the deltas that it found were different after calculation.
It will use a previous version of the package stored on the Tentacle and rebuild the package using the difference before the package is then deployed as a whole.

This is copied from the documentation page below and explains the process.

1: Find nearest previous versions of the package on the Tentacle by calling Calamari
2: If a previous version of a package is found and the same package (matching PackageId, Version and file hash) exist on the Octopus Server
A: Create a signature file for the nearest package found
B: Build the delta between the previous package (using the above signature file) and the new package
C: Upload delta file to Tentacle and call Calamari to apply the delta file to the package found in the previous step
3: If no previous version of the package was found, we upload the full package instead
http://docs.octopus.com/display/OD/Delta+compression+for+package+transfers

If you have any further questions or issues please don’t hesitate to let me know.

Regards,
Daniel

Aditya · 28 June 2016 05:24

Thanks a lot .

Best Regards
Aditya