How would you avoid losing objects / development code if your development environment crashed and was restored?

We recently had the following scenario on our cloud based Appian environment.

1. We do all our application building / designing / development on our development environment.
2. We promote our applications to our QC environment and finally Production.
3. Our development environment recently had issues where the Appian support team had to restore it to a point from the previous day.
4. Once our development environment had been restored to the previous days recovery point, we had effectively lost all our application development from the recovery point to the time the server became unstable.


Question: What is your process to avoid or mitigate this loss of work/code if your dev environment crashes ?


I come from a non-Appian environment where we develop our source code and then commit it to a source code repository.
From there it automatically checks the source code for quality, builds the application, and deploys it to our development environment.
If our development environment crashes for any reason and we need to restore it, we don't lose any developer productivity or source code as it is safely tucked away in our source code repository.

It is absurd to me that we lost developer productivity / source code because our Appian development environment crashed.


I would love to hear everyone's take on the above and thoughts on best practice around this within an Appian environment.

  Discussion posts and replies are publicly visible

Parents
  • Certified Lead Developer

    I've been on dev teams for projects on cloud envronments consistently for over 10 years (sometimes more than one at once) and have never actually seen a rollback required like this.  I guess you could say it becomes a risk:benefit analysis of the hundreds (or thousands) of person hours saved over accumulated time by not having to bend over backwards and take extra manual steps to back up progress for each small incremental change made, versus losing a single day of development effort. 

    That said, the new version allegedly now has some new programmatic deployment features, which (may?) include some way to set up automated export of certain application packages in such a way that they can be safely stored elsewhere.  I'm not sure what the full feature set is there, but it might be worth looking further into.

Reply
  • Certified Lead Developer

    I've been on dev teams for projects on cloud envronments consistently for over 10 years (sometimes more than one at once) and have never actually seen a rollback required like this.  I guess you could say it becomes a risk:benefit analysis of the hundreds (or thousands) of person hours saved over accumulated time by not having to bend over backwards and take extra manual steps to back up progress for each small incremental change made, versus losing a single day of development effort. 

    That said, the new version allegedly now has some new programmatic deployment features, which (may?) include some way to set up automated export of certain application packages in such a way that they can be safely stored elsewhere.  I'm not sure what the full feature set is there, but it might be worth looking further into.

Children
No Data