Navigation

    Inedo Community Forums

    Forums

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    1. Home
    2. sylvain.martel_3976
    S
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    sylvain.martel_3976

    @sylvain.martel_3976

    0
    Reputation
    5
    Posts
    1
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    sylvain.martel_3976 Follow

    Best posts made by sylvain.martel_3976

    This user hasn't posted anything yet.

    Latest posts made by sylvain.martel_3976

    • RE: Support for Winget feed

      @apxltd said in Support for Winget feed:

      Can you give an estimate of the number of Winget "packages" you expect to have in your feed? Like 10? 100? 1000?

      We currently have over 300 SCCM packages for servers. We expect to convert them all in the end.

      What would the process of adding a third-party application to this feed? Will you be recreating the WinGet metadata (package?) from Microsoft's official feed?

      No idea about this. :-/

      Are most of these third-party applications in Microsoft's feed, or are they like from vendors or whatnot?

      Well, since winget is pretty new, not many "complex" app are in the Microsoft feed yet(like some dreaded IBM or Oracle applications with their java installer) And because of our internal requirement, we mostly build our install scripts from scratch, using the vendors msi, exe, etc.

      Is this just like an ordinary file server, where you use UNC paths? We are have plans to do some major improvements on ProGet's Asset Directory, including enabling replication, cloud storage, and (hopefully) versioning.

      Yes, they are simple file servers with shared folders, accessed through UNC.

      So to summarize your usecase...

      • WinGet is a means to manage (mostly) third-party applications that you keep on a private file server, and wish to install on other servers through automation
      • WinGet is preferred to a regular file server because it includes some metadata like requirements on what to install
      • WinGet is preferred to Chocolatey for security and cost reasons

      Correct on all 3, although I wouldn't say choco is not secure, but mostly, it's client is difficult to deploy and the cost of the enterprise version is prohibitive for us.

      What I'd like to do is build a usecase for how organizations can use WinGet in combination with ProGet (in particular the asset directories) to add value.

      posted in Support
      S
      sylvain.martel_3976
    • RE: Support for Winget feed

      @apxltd said in Support for Winget feed:

      Our plan is to use Winget to deploy apps on servers using ansible playbook.

      Can you tell us more about this? Lots of questions, hope you don't mind us trying to understand a bit more...

      What apps? As in, applications your company created (first-party apps), or third-party ones (like Firefox or SQL Server, etc).

      All. First-party and 3rd party. 90% 3rd party though.

      We used SCCM to deploy applications on servers, using regular powershell scripts, but we are moving away from that for the server side since we started using terraform/ansible a year ago and are redoing everything using IaC(infrastructure as code) now to code our infra(and help move to the cloud). So we want to deploy those applications with those tools, which also allow for much more control on what is present or not on a srever. Using winget should help to solve some lingering problems too that we have on the windows side, like dependencies of packages that could now be linked directly inside the manifest. Chocolatey could solve the dependencies part too, but as mentioned in the previous post, there were some problemswith choco, mostly non-technicals, that forced us to stop considering it, sadly.

      Where to host contents? WinGet doesn't seem to host the installers or package contents, so where will you host these files? Will you keep them on the internet (third-party apps), or have your own custom source (like a CDN or ProGet Asset Directory)

      Well, we use a file server to host the packages. We can't use anything hosted on the internet since, for security reasons, the servers do not have internet access. That is one of the main reason we started using proget for python libraries and powershell modules, to be able to deploy them internally with ease and be sure the right versions are deployed/present on the servers.

      [First-party / custom apps] Do you already make installers for your apps? If not, how will you automate installation?

      Well, most first-party apps are deployed directly from the compilation pipeline. For the rest, the method of deployment depends highly on the form factor of the app(web app, executable, etc). It's often a powershell script when it's not deployed from the pipeline directly.

      [First-party / custom apps], Have you explored ProGet's Universal Packages instead? I think these would be better/easier, especially for server applications. We've seen a lot of people use these over Chocolatey.

      Proget is fairly new in our environment. I asked for it to be acquired this year because, in our move toward IaC ,we required a powershell repo for powershell DSC modules since servers do not have internet access, so powershellgallery was off-limit. Since then, it's role also expanded a bit to supply some python libraries since AzureDevops only support nuget feeds and a project required python libs. So no, we haven't looked at all at that feature of proget.

      [Third-party apps] Why use a private feed? Is it for security/vulnerability? Quality checking? Etc.

      Security still stick to their old recommendations of not allowing internet access to public sources, even when they are managed by the suppliers themselves. So we need to have our internal feeds or use old methods like copying manually(which is not even possible anymore for many kind of packages, so the feeds are the way to go for us since we also can supply version numbers for conformity checking when using IaC)
      It's also a way to control what modules can be used. I do not agree with that part, since it adds an insane overhead of bringing the packages in-house, but I have no say over that decision :P (No internet access is also the reason we have to use the "classic" installer for proget itself, and that is also a huge pain for updates. I wish we could use the normal process, but can't.)

      But even if we could access public repos directly, nother reason not to use them as-is, is that scripts from third-part rarely fit our corporate envrironnment. When I tested some choco packages a year ago, we always had to do modifications to the scripts to fit our needs/requirements.

      posted in Support
      S
      sylvain.martel_3976
    • RE: Support for Winget feed

      Found a nice article that describe it better than I can :) (english isn't my primary language)
      https://www.infoworld.com/article/3611365/getting-started-with-winget-the-windows-package-manager.html

      posted in Support
      S
      sylvain.martel_3976
    • RE: Support for Winget feed

      @dean-houston Hi, well, winget is a bit like apt-get on linux(in fact, winget is based on AppGet codebase which tried to reproduce apt-get on windows). The yaml is a document describing what is required to run the application, pretty much like chocolatey base template requires. Since it's a 1.0 version, we expect alot more functionality to appear in the coming months.

      For us, Winget will solve a huge problem that chocolatey has: Meaning, it's not part of Windows and installing the client is actually really difficult to deploy/install with automation tools like ansible(or at least it was last time we checked it, about a year ago.) Management is also a tad cold at giving us the go to use chocolatey since the enterprise version of Choco doesn't have a really big userbase and does become expensive rapidly. Development also move forward slowly.(again, that was a year ago, but we put it aside for those reasons)

      But of course, we'll also require the "feed" part for the winget client to work, and we use proget for our feeds internaly.(powershell modules, python libraries, and some RPM)

      Our plan is to use Winget to deploy apps on servers using ansible playbook.

      posted in Support
      S
      sylvain.martel_3976
    • Support for Winget feed

      Hi,

      The winget client v1.0 finally got released! Will proget add that feed type soon?

      The reference implementation for the REST API is located here https://github.com/microsoft/winget-cli-restsource

      Being a windows shop, we are eagerly awaiting this feature! :)

      posted in Support
      S
      sylvain.martel_3976