5 ms·

this list is a very simple algorithm. Why don't you tun it into a script deploy.sh ?

by enriquto 7y ago

vortico 7y ago
No it's not.
- enriquto 7y ago
  But it almost is, already! Half of the lines are literally shell commands. And except maybe for the legal check, the rest of the steps can also be written as shell one-liners. For example, to update the version on a README file you can "sed -i" with an appropriate replacement, and so on.
  - vortico 7y ago
    Can you explain how your ./deploy.sh script forks onto three laptops (Windows/Mac/Linux) and "plays around" with the installers/build a bit to make sure it works? I obviously can't release builds that don't even run because I didn't take a few minutes to test them.
    - enriquto 7y ago
      Why don't you use virtual machines?
      - vortico 7y ago
        Good question. 1) A MacOS virtual machine is probably illegal. 2) I need to test the builds on all three machines, and VMs don't handle OpenGL, USB drivers (e.g. for MIDI controllers), and audio drivers very well or at all. 3) I need to have a rough idea of performance of the build. VMs affect performance by non-constant/unpredictable factors. For example, CPU performance might be 1x the speed of a bare-metal OS, but graphics performance might be 0.25x. 4) I don't know how to write a shell script on a host computer that launches Windows 10 and runs commands with an MSYS2 Mingw64 shell.
        mr_mitm 7y ago
        > I don't know how to write a shell script on a host computer that launches Windows 10 and runs commands with an MSYS2 Mingw64 shell. Launching a VM via shell script is trivial. And you can install OpenSSH on Windows 10: https://github.com/PowerShell/Win32-OpenSSH https://github.com/PowerShell/Win32-OpenSSH
        enriquto 7y ago
        > A MacOS virtual machine is probably illegal. true. And that is a very sad state of affairs. I use the travis osx hosts for that, but it's not ideal. There's no interface, but at least you can check that the code compiles, runs, and passes automated tests. That's already huge! For linux and windows hosts, it seems to me that it is a solved problem, as pointed elsewhere.
        deleted 7y ago
        [deleted]
        jakobegger 7y ago
        > A MacOS virtual machine is probably illegal. It's not, as long as you run it on genuine Apple hardware. We use a bunch of macOS VMs that are 100% legal. The problem with macOS VMs is that there are a lot of compatibility issues, and in my experience it's a lot of effort to set up macOS VMs. If you have the space and the money, real machines are a lot easier to deal with.
      - jakobegger 7y ago
        We use a combination of real machines and VMs for building software, and dealing with macOS VMs is a major hassle. There are always compatibility issues that are hard to debug (eg. don't try to configure your VM to use more than 2 vCPUs if you want to run macOS 10.12). There is a lot of manual work that goes into maintaining VMs, and often automating those tasks doesn't pay off. If your app has any GUI components, those are often buggy in VMs (anything using the GPU is extremely unreliable). Our main build machine is an actual Mac, because it's just so much easier to keep it running. VMs are nice if you need a lot of different setups (eg. one app we distribute has components that need to be built on different versions of macOS, and VMs are nice for that).
    - cobbzilla 7y ago
      Sounds like you are mixing release & QA, makes a lot of sense in a small shop. In a larger team you’d have a small agent on each of your N (likely >> 3) machines, CI pushes to the agent for build/release/automated tests. Then if those pass on a given system, it fires off a message to start manual QA validation for performance and other “intangibles”.
tbrownaw 7y ago
Some of the steps look like they'd be hard to do that for. Like for example the one about making sure the license is correct, and the one about testing parts that apparently don't have good automated tests / interact with the real world.
- enriquto 7y ago
  > Some of the steps look like they'd be hard to do that for. Then those steps must be removed. I thought the mantra "deploy is ONE step" was a more or less universally acknowledged truth.
  - antoinevg 7y ago
    It looks like you're new here. Please repeat after me: In software engineering there are no more or less universally acknowledged truths.
    - yjftsjthsd-h 7y ago
      Unfortunately, not everyone acknowledges this truth;)
      - antoinevg 7y ago
        …or has a sense of humour about it! ;-)
  - creatornator 7y ago
    I mean unless a computer can check that all dependencies have compatible licenses, that is unrealistic. It's a necessary step for publicly released software to avoid legal issues
    - cyphar 7y ago
      Linux distributions (though I can only speak to openSUSE's process) have automated scripts (which I believe are written by our lawyers) which check whether the license of a package matches the license of the files inside the package. It's how most package legal review gets done (and if the script can't figure it out, it gets escalated to our actual lawyers too review. You cannot submit a package to any one of the distributions we ship without the legal review being approved. So it is clearly possible to do -- and there are all sorts of tools which figure out what SPDX license entries apply for every dependency (or vendored dependency) of a given project.
happytoexplain 7y ago
How have you come to that conclusion?
gdfasfklshg4 7y ago
Because it involves inherently manual processes.

this list is a very simple algorithm. Why don't you tun it into a script deploy.sh ?

vortico 7y ago

No it's not.

enriquto 7y ago
But it almost is, already! Half of the lines are literally shell commands. And except maybe for the legal check, the rest of the steps can also be written as shell one-liners. For example, to update the version on a README file you can "sed -i" with an appropriate replacement, and so on.
- vortico 7y ago
  Can you explain how your ./deploy.sh script forks onto three laptops (Windows/Mac/Linux) and "plays around" with the installers/build a bit to make sure it works? I obviously can't release builds that don't even run because I didn't take a few minutes to test them.
  - enriquto 7y ago
    Why don't you use virtual machines?
    - vortico 7y ago
      Good question. 1) A MacOS virtual machine is probably illegal. 2) I need to test the builds on all three machines, and VMs don't handle OpenGL, USB drivers (e.g. for MIDI controllers), and audio drivers very well or at all. 3) I need to have a rough idea of performance of the build. VMs affect performance by non-constant/unpredictable factors. For example, CPU performance might be 1x the speed of a bare-metal OS, but graphics performance might be 0.25x. 4) I don't know how to write a shell script on a host computer that launches Windows 10 and runs commands with an MSYS2 Mingw64 shell.
      - mr_mitm 7y ago
        > I don't know how to write a shell script on a host computer that launches Windows 10 and runs commands with an MSYS2 Mingw64 shell. Launching a VM via shell script is trivial. And you can install OpenSSH on Windows 10: https://github.com/PowerShell/Win32-OpenSSH https://github.com/PowerShell/Win32-OpenSSH
      - enriquto 7y ago
        > A MacOS virtual machine is probably illegal. true. And that is a very sad state of affairs. I use the travis osx hosts for that, but it's not ideal. There's no interface, but at least you can check that the code compiles, runs, and passes automated tests. That's already huge! For linux and windows hosts, it seems to me that it is a solved problem, as pointed elsewhere.
        deleted 7y ago
        [deleted]
        jakobegger 7y ago
        > A MacOS virtual machine is probably illegal. It's not, as long as you run it on genuine Apple hardware. We use a bunch of macOS VMs that are 100% legal. The problem with macOS VMs is that there are a lot of compatibility issues, and in my experience it's a lot of effort to set up macOS VMs. If you have the space and the money, real machines are a lot easier to deal with.
    - jakobegger 7y ago
      We use a combination of real machines and VMs for building software, and dealing with macOS VMs is a major hassle. There are always compatibility issues that are hard to debug (eg. don't try to configure your VM to use more than 2 vCPUs if you want to run macOS 10.12). There is a lot of manual work that goes into maintaining VMs, and often automating those tasks doesn't pay off. If your app has any GUI components, those are often buggy in VMs (anything using the GPU is extremely unreliable). Our main build machine is an actual Mac, because it's just so much easier to keep it running. VMs are nice if you need a lot of different setups (eg. one app we distribute has components that need to be built on different versions of macOS, and VMs are nice for that).
  - cobbzilla 7y ago
    Sounds like you are mixing release & QA, makes a lot of sense in a small shop. In a larger team you’d have a small agent on each of your N (likely >> 3) machines, CI pushes to the agent for build/release/automated tests. Then if those pass on a given system, it fires off a message to start manual QA validation for performance and other “intangibles”.

tbrownaw 7y ago

Some of the steps look like they'd be hard to do that for. Like for example the one about making sure the license is correct, and the one about testing parts that apparently don't have good automated tests / interact with the real world.

enriquto 7y ago
> Some of the steps look like they'd be hard to do that for. Then those steps must be removed. I thought the mantra "deploy is ONE step" was a more or less universally acknowledged truth.
- antoinevg 7y ago
  It looks like you're new here. Please repeat after me: In software engineering there are no more or less universally acknowledged truths.
  - yjftsjthsd-h 7y ago
    Unfortunately, not everyone acknowledges this truth;)
    - antoinevg 7y ago
      …or has a sense of humour about it! ;-)
- creatornator 7y ago
  I mean unless a computer can check that all dependencies have compatible licenses, that is unrealistic. It's a necessary step for publicly released software to avoid legal issues
  - cyphar 7y ago
    Linux distributions (though I can only speak to openSUSE's process) have automated scripts (which I believe are written by our lawyers) which check whether the license of a package matches the license of the files inside the package. It's how most package legal review gets done (and if the script can't figure it out, it gets escalated to our actual lawyers too review. You cannot submit a package to any one of the distributions we ship without the legal review being approved. So it is clearly possible to do -- and there are all sorts of tools which figure out what SPDX license entries apply for every dependency (or vendored dependency) of a given project.

happytoexplain 7y ago

How have you come to that conclusion?

gdfasfklshg4 7y ago

Because it involves inherently manual processes.