4 ms·

Using the same OS that you deploy to

by indy 10y ago

konart 10y ago
To be honest - kernel will be the same (some times not though). OS will be most likely different. Better say that environment will be the same, I guess. That being said - as an ex-Linux user (for about 10 years) I see now real reason for this kind of switch. You can have the same (or almost the same) env on you macOS.
- neverminder 10y ago
  If we take the most popular linux choice for servers and desktop - Ubuntu as an example - that means using identical kernel/packages/libraries for your development and production. You cannot achieve that with MacOS as your dev OS.
  - konart 10y ago
    Desktop - most likely, server - I wouldn't be so sure. Kernel - obviously, as I said earlier. As for packages and libs - Brew + something like pip\rvm\whatever will most likely solve this for you. You won't have the same lib, because it was build for a different env, but the way it works should stay the same. If not - I'd rather consider using different lib. This + docker(or something similar) as someone already mentioned.
  - jawngee 10y ago
    You can with vagrant + parallels/virtual box/vmware.
  - pjmlp 10y ago
    That doesn't matter at all when using programming languages with OS agnostic runtimes[0]. Also, unless IT agrees to put beefy machines under each one's desk, the server is quite different from what developers can use anyway. Finally if there is any issue that really needs testing on the server, that is what remote connections (including remote debugging) are for. [0] We usually develop on Windows and deploy on UNIX.
    - mugsie 10y ago
      You would be surprised what can happen with "agnostic runtimes" Running the same libraries, on the same base OS is invaluable to me - but that can depend on what you are developing. > Also, unless IT agrees to put beefy machines under each one's desk, the server is quite different from what developers can use anyway. With "the cloud", these days that is not necessarily true. a t2.large / m2.large are 2 cores, 8GB RAM. - well within the reach of a basic laptop. > Finally if there is any issue that really needs testing on the server, that is what remote connections (including remote debugging) are for. Never debug in production. No developer should have access to production.
      - pjmlp 10y ago
        > With "the cloud", these days that is not necessarily true. a t2.large / m2.large are 2 cores, 8GB RAM. - well within the reach of a basic laptop. Which is why we just connect to "cloud" and clone our own instance from a production server, if we really need to. > Never debug in production. No developer should have access to production. Maybe in a perfect world. On real life I have been in projects where developers were exchanging dlls and jar files on them.
        mugsie 10y ago
        OK, the problems seem more culture based then. All of these issues tie together. Developers can't access production, so they start using production like environments, which allows for proper Ops work (Infrastructure as code - e.g. config management), which allows for easier setup of production like environments for developers ... and continue cycle. Its hard to move to that, and takes time, but it really helps. I know it can seem overkill, especially for small teams, but the tech debt paydown that happens when you end up doing it in the future can be huge, and massively disruptive.
        pjmlp 10y ago
        I kind of agree, but to be honest I have been on and off of server side projects since the mid-90's, and can count up to five the amount of projects "done the right way".
walshemj 10y ago
Amen! back when I was working using SUN gear we deliberately brought all the hardware from the same production run so that the hardware would be 100% identical. Our main hardware guy would have liked to make sure all the DASD (Disks) where from the same production run as well.

Using the same OS that you deploy to

by indy 10y ago

Using the same OS that you deploy to

To be honest - kernel will be the same (some times not though). OS will be most likely different. Better say that environment will be the same, I guess. That being said - as an ex-Linux user (for about 10 years) I see now real reason for this kind of switch. You can have the same (or almost the same) env on you macOS.

neverminder 10y ago
If we take the most popular linux choice for servers and desktop - Ubuntu as an example - that means using identical kernel/packages/libraries for your development and production. You cannot achieve that with MacOS as your dev OS.
- konart 10y ago
  Desktop - most likely, server - I wouldn't be so sure. Kernel - obviously, as I said earlier. As for packages and libs - Brew + something like pip\rvm\whatever will most likely solve this for you. You won't have the same lib, because it was build for a different env, but the way it works should stay the same. If not - I'd rather consider using different lib. This + docker(or something similar) as someone already mentioned.
- jawngee 10y ago
  You can with vagrant + parallels/virtual box/vmware.
- pjmlp 10y ago
  That doesn't matter at all when using programming languages with OS agnostic runtimes[0]. Also, unless IT agrees to put beefy machines under each one's desk, the server is quite different from what developers can use anyway. Finally if there is any issue that really needs testing on the server, that is what remote connections (including remote debugging) are for. [0] We usually develop on Windows and deploy on UNIX.
  - mugsie 10y ago
    You would be surprised what can happen with "agnostic runtimes" Running the same libraries, on the same base OS is invaluable to me - but that can depend on what you are developing. > Also, unless IT agrees to put beefy machines under each one's desk, the server is quite different from what developers can use anyway. With "the cloud", these days that is not necessarily true. a t2.large / m2.large are 2 cores, 8GB RAM. - well within the reach of a basic laptop. > Finally if there is any issue that really needs testing on the server, that is what remote connections (including remote debugging) are for. Never debug in production. No developer should have access to production.
    - pjmlp 10y ago
      > With "the cloud", these days that is not necessarily true. a t2.large / m2.large are 2 cores, 8GB RAM. - well within the reach of a basic laptop. Which is why we just connect to "cloud" and clone our own instance from a production server, if we really need to. > Never debug in production. No developer should have access to production. Maybe in a perfect world. On real life I have been in projects where developers were exchanging dlls and jar files on them.
      - mugsie 10y ago
        OK, the problems seem more culture based then. All of these issues tie together. Developers can't access production, so they start using production like environments, which allows for proper Ops work (Infrastructure as code - e.g. config management), which allows for easier setup of production like environments for developers ... and continue cycle. Its hard to move to that, and takes time, but it really helps. I know it can seem overkill, especially for small teams, but the tech debt paydown that happens when you end up doing it in the future can be huge, and massively disruptive.
        pjmlp 10y ago
        I kind of agree, but to be honest I have been on and off of server side projects since the mid-90's, and can count up to five the amount of projects "done the right way".

walshemj 10y ago

Amen! back when I was working using SUN gear we deliberately brought all the hardware from the same production run so that the hardware would be 100% identical. Our main hardware guy would have liked to make sure all the DASD (Disks) where from the same production run as well.