raspiBackup is developed primarily on a Linux desktop. But finally raspiBackup is tested on a real Raspberry. There exist various raspibian images on disk which are restrored with raspiBackup on a SD card and/or USB stick and then the new or changed functionality of raspiBackup ist tested manually.
At some point in time a new version of raspiBackup has to be published. Initially I tested a lot of different variants by hand which takes a long time and reduces the number of my SD cards. Therefore I set up a Raspberry simulation environment on Linux. Now every new raspiBackup version is regression tested in the simulation environment. That's much faster and I don't have to buy new SD cards all the time any more.
On the following picture you can see a 3B Raspberry I use for tests together with various SD cards of different size and USB sticks.
All sourcecode is maintained in a local git repository. New releases are maintained in a development branch.
If the new release is ready to be published it's announced as beta. Before publishing a new release it's announced as beta. Would be great if users of raspiBackup test this beta on their local environment and give feedback. At the same time the beta is regressiontested and used on my local environments for about 4 weeks . Then it's merged into the master branch and published. raspiBackup is Open Source and therefore all releases are synced to github. Even the development branch is synced from time to time.
raspiBackup writes it's git code version (commit sha) in the following message RBK0009I
--- RBK0009I: raspifix: raspiBackup.sh V0.6.3.2 (5c98a16) started at Sun Jun 3 09:46:08 CEST 2018
The hex number in parentheses (5c98a16 in this example) allows me to retrieve the matching code whenever there is an issue reported against raspiBackup and to start problem determination. Therefore it's important to report message RBK0009I in every issue. In addition it's possible to create a hotfix on the raspiBackup code level the issue was reported on. I usually build a hotfix and ask the issue reporter to verify the fix before rolling in the fix into the next release.