3 ms·

Access to production environment is not the only issue here. Proper testing in development environment is not very practical without restoring a backup from pr

Access to production environment is not the only issue here. Proper testing in development environment is not very practical without restoring a backup from production environment. So typically, even if developers cannot change production data, they still can read few weeks old copy from production environment. Trimming production data after restoring it to development may improve security a little bit, but such trimming is a project in itself and requires constant maintenance of that trimming code. In addition to that, trimming production backup may introduce new bugs in development and make production bugs not reproducible in development environment.

patio11 12y ago
I would strenuously, strenuously argue against ever, at any stage of the company, at any kind of company, with any data of any significance whatsoever, letting developers initialize dev environments with production backups. That's not a disaster waiting to happen. It's a fractal of disasters -- no matter which part of the idea you examine, it has an infinite number of disasters in it. It is an Ice-9 of disasters: you introduce it to perfectly sensible engineering decisions and they become disasters, too, just by contact with it. ("Do we let our developers work on laptops?" "Sure." Great, now our production database is one car window away from causing catastrophic reputational damage to the company.)
- dennisgorelik 12y ago
  In a small team there should be single development database restored from backup. That development database should be hosted on development server, not on developers' laptops. Developers are welcome to VPN into corporate network from their laptops in order to work with database. Any other issues?
  - collyw 12y ago
    That doesn't make sense. What if people want to change the database schema, and 4 developers are working on it at once?
    - opendais 12y ago
      What we do at work is every developer has their own VM on an on-premise server in a locked room that is rebuilt/destroyed as needed with the full stack. So maybe he just wasn't being clear?
    - dennisgorelik 12y ago
      Breaking database changes do not happen often. There could be multiple solutions to that: 1) Other developers wait. 2) Affected functionality is turned off while in transition. 3) Changes implemented in a non-breaking way. 4) Change is done quickly. 5) Separate database environment is setup in order to prepare change. In any case, the harder problem is to deploy that database change into production when thousands of users are working on it at once. Practicing that change in development environment helps to make production deployment smoother.
      - collyw 12y ago
        Fair enough, I am guessing your work is at a different scale from mine. We are "super agile" (constantly changing) due to the changing nature of the sequencing technology we work with.

patio11 12y ago

I would strenuously, strenuously argue against ever, at any stage of the company, at any kind of company, with any data of any significance whatsoever, letting developers initialize dev environments with production backups. That's not a disaster waiting to happen. It's a fractal of disasters -- no matter which part of the idea you examine, it has an infinite number of disasters in it. It is an Ice-9 of disasters: you introduce it to perfectly sensible engineering decisions and they become disasters, too, just by contact with it. ("Do we let our developers work on laptops?" "Sure." Great, now our production database is one car window away from causing catastrophic reputational damage to the company.)

dennisgorelik 12y ago
In a small team there should be single development database restored from backup. That development database should be hosted on development server, not on developers' laptops. Developers are welcome to VPN into corporate network from their laptops in order to work with database. Any other issues?
- collyw 12y ago
  That doesn't make sense. What if people want to change the database schema, and 4 developers are working on it at once?
  - opendais 12y ago
    What we do at work is every developer has their own VM on an on-premise server in a locked room that is rebuilt/destroyed as needed with the full stack. So maybe he just wasn't being clear?
  - dennisgorelik 12y ago
    Breaking database changes do not happen often. There could be multiple solutions to that: 1) Other developers wait. 2) Affected functionality is turned off while in transition. 3) Changes implemented in a non-breaking way. 4) Change is done quickly. 5) Separate database environment is setup in order to prepare change. In any case, the harder problem is to deploy that database change into production when thousands of users are working on it at once. Practicing that change in development environment helps to make production deployment smoother.
    - collyw 12y ago
      Fair enough, I am guessing your work is at a different scale from mine. We are "super agile" (constantly changing) due to the changing nature of the sequencing technology we work with.