3 ms·

Article seems a bit over the top. Many of us can and do have a rollback button. Sure, rolling back isn't trivial. If the code has side effects (e.g. database,

by craigds 10y ago

Article seems a bit over the top. Many of us can and do have a rollback button. Sure, rolling back isn't trivial. If the code has side effects (e.g. database, disk or cache state), you need to account for those side effects when rolling back. The example given in the article could be easily fixed by adding a cache.clear() to the rollback procedure (assuming cache performance isn't considered panic-critical) For database state, use a migration system and make sure each change you make can be reversed (and make sure that's tested!) > If developers incorrectly believe that their mistakes can be quickly reversed, they will tend to take more foolish risks. It might be hard to talk them out of it. I doubt it. Either encourage rapid iteration and deployment, or encourage a more stable, well-tested production environment. Do that via feedback, code reviews, post-mortems, internal docs. The presence or absence of a rollback button is not going to a major contributor to this.

sudhirj 10y ago
> For database state, use a migration system and make sure each change you make can be reversed (and make sure that's tested!) Isn't this debunked clearly in the article? If you add a new feature / column and users begin using it (adding data, making transactions) rolling back is a catastrophic data loss. Sure, the code and database schema will go back to a consistent state, but the data never can. That's what the is pointing out - that deployed applications + data are a state machine without cycles - i.e., even if you 'rollback', it's akin to adding a revert commit on top of your existing state. The arrow of state, as with time, only moves forward.
- stuaxo 10y ago
  This is true. However probably the vast majority of websites are small or medium sized where losing a few minutes data won't matter.
- kelnos 10y ago
  That's why you don't do it that way. Adding a new column to a database table (for example) is a single distinct deployment. You do that one without touching your application code. After the column has been added, you deploy the code that uses it. If the new column is a replacement for an existing column, your new code should continue to write to the existing column as well in the same way it always has. If you have to roll back, you roll back the application code change, but the database change remains, so there's no problem. Meanwhile, the new code that was rolled back was still writing to the existing column, so there's no data missing that the old code expects to be there. After you are comfortable with the change, you can update your code to stop using the obsolete column, test that change, and then later drop the column from the database table. If you've added a new column or database table for a new type of data, and have to roll back the application code that uses it, you don't lose any data. The customer is of course unable to use the new feature and new data post-rollback, but that's okay: you can roll out the new feature again when you've figured out what the problem is. Yes, I'm sure we can all come up with examples where this approach won't work, but they are not the norm. The are rare. If they are not, then you are doing infrastructure wrong.
  - brightball 10y ago
    Exactly. Perfect.
pif 10y ago
> and make sure that's tested! If everything is tested, the rollback button is useless!

by craigds 10y ago

sudhirj 10y ago

> For database state, use a migration system and make sure each change you make can be reversed (and make sure that's tested!) Isn't this debunked clearly in the article? If you add a new feature / column and users begin using it (adding data, making transactions) rolling back is a catastrophic data loss. Sure, the code and database schema will go back to a consistent state, but the data never can. That's what the is pointing out - that deployed applications + data are a state machine without cycles - i.e., even if you 'rollback', it's akin to adding a revert commit on top of your existing state. The arrow of state, as with time, only moves forward.

stuaxo 10y ago
This is true. However probably the vast majority of websites are small or medium sized where losing a few minutes data won't matter.
kelnos 10y ago
That's why you don't do it that way. Adding a new column to a database table (for example) is a single distinct deployment. You do that one without touching your application code. After the column has been added, you deploy the code that uses it. If the new column is a replacement for an existing column, your new code should continue to write to the existing column as well in the same way it always has. If you have to roll back, you roll back the application code change, but the database change remains, so there's no problem. Meanwhile, the new code that was rolled back was still writing to the existing column, so there's no data missing that the old code expects to be there. After you are comfortable with the change, you can update your code to stop using the obsolete column, test that change, and then later drop the column from the database table. If you've added a new column or database table for a new type of data, and have to roll back the application code that uses it, you don't lose any data. The customer is of course unable to use the new feature and new data post-rollback, but that's okay: you can roll out the new feature again when you've figured out what the problem is. Yes, I'm sure we can all come up with examples where this approach won't work, but they are not the norm. The are rare. If they are not, then you are doing infrastructure wrong.
- brightball 10y ago
  Exactly. Perfect.

pif 10y ago

> and make sure that's tested! If everything is tested, the rollback button is useless!