Package update strategy

[f4242]

Hello,

what is your strategy for updating WAPT packages across your network?

I'm aiming for a monthly update with a pre-deployment in a small environment with a few workstations (maturity STAGING) followed by a large-scale deployment a few days later (maturity PROD).

Each month, I have to check each package to see if an update exists and, if so, deploy it. Over time, the number of packages increases, and the time required increases accordingly. Fortunately, most packages have an `update_package` function that allows for quick repackaging. However, finding the packages to update is a manual operation (consulting the developers'/distributors' websites).

After that, all the packages have to be modified again to rebuild them in the PROD environment.

Do you have any tips for speeding up the deployment of updates to your workstations?

Personally, I've thought of two things that could help, but they require changes to WAPT.

The first improvement would be to add an `update_check` function to packages, which would return `true` if updates are available upstream. This function could query a website, much like the `update_package` function. A way to display this information in the WAPT console would need to be found. This would automate the search for packages to update.

The second improvement would be the ability to rebuild a package with a single click in the console to transfer it to the production environment. Ideally, I could select multiple packages at once and let them rebuild automatically.

Thank you!

[sfonteneau]

Hello,

we already have an internal method for this (managed outside of WAPT).

This script retrieves the latest software versions from the publishers' official websites.
If the software version has changed since the last check, the script also triggers a Jenkins build of the associated package, executes the update_package for that package, and then uploads it to a temporary server (sending us a notification in the process).
From this point on, human intervention begins; the user must verify and test the package. If everything is correct, then the package can be deployed to production.

As a bonus, the script sends a notification to a Twitter account
: https://twitter.com/patchmanagement

[f4242]

Interesting. Build automation is something I'd also like to implement someday. We usually use GitLab CI here, but I suppose I could do something similar. Is your build server on Windows or Linux?

I'll probably start with a notification script and then, when time allows, move on to build automation.

[sfonteneau]

We have a Gitea that manages package recipes.
The Gitea has one repository per package (the repository does not host binaries).

Each repository has a Jenkinsfile that defines what Jenkins should do. (The Jenkinsfile is still present in our public packages.)

When we run a build on Jenkins, Jenkins clones the repository and executes the Jenkinsfile on a Windows Jenkins slave.

So our Jenkins server is on Linux, but its slave is on Windows.

[f4242]

Thanks for the info. I'll keep that in mind

[Mathieu]

Hello,

is it possible to add this function to WAPT?

I'm subscribed to the Ants' Twitter and newsletter (I'm no longer receiving emails, by the way). Implementing a tool like this in WAPT would really save time, as going through each package to update and then upload it takes a long time.

[sfonteneau]

Is it possible to add this function to WAPT?

We are entering a phase of continuous integration.
At worst, we can document this work so that it can be reproduced for you, but without going any further.

I am subscribed to the Ants' Twitter and newsletter (I no longer receive emails, by the way),

I can see that you registered this morning at 09:25

Implementing a tool of this kind in WAPT would really save time, because going through each package to do an update and then upload takes time.

I can help you set that up. To do so, you will first need:
- A Jenkins
- A Gitea
- A Windows Slave