Archiving Strategy
Peter Rousseau
I'm getting myself all twisted up when it comes to saving/archiving
stuff. I have been archiving forms whenever I modify one to the point
that if it becomes broken that there is no way I will be able to "go
back" because there are just too many changes. The problem I've run into
is when the tables have been restructured.
Maybe I should base archiving decisions on when tables or data models
have been changed?
I would like to hear some strategies to help me get a starting point.
Thank you.
Peter R
spiraling out of control \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/...
Tom Krieg
Peter,
The first thing you need to do is to have a **production** copy of your
system and a **development** copy. To begin with, they need to be
exactly the same, tested and **working**. Give each one the same version
number.
Never, ever make any changes to any forms, tables etc in the production
copy. Do your development work (backing up regularly) on the development
copy. Test, test and retest. In fact, give your users a beta copy to
test as well. Then give your development copy a version (or build)
number (incremented from your production copy). Document and spec all
the changes you've made. When you've exhaustively tested, document your
conversion from development to production. Convert the tables (or
transfer old data to new tables) if necessary, then copy development to
production. Remember to make backup copies of your old system **before**
you do this. Then make a backup copy of your new production system.
This way, you never overwite something that's working with something
that's not. Remember that documentation is crucial.
HTH
Tom Krieg
Peter Rousseau
Hi Tom:
Thanks for the reply, I'm going to work on implementing your suggestion. What
triggers the backup, a restructured table/data model or changes in the form?
Peter R
Tom Krieg
Peter,
I plan my development based on user "requests" or planned updates and
modifications. You need to freeze new requests at some point, and have a
documented list of the things you're going to change and the new
features you're including. (You can still collect other change requests
and write down new ideas, just seperate them for "the next version after
this one"). So you have a ***working*** system, and documented specs for
changes, additions and modifications to be incorporated in the new
version. What are you waiting for? Get to work <g> Back up your
development system every day, so you don't lose work (even if it's in
bits and pieces and untested/with compile errors etc). Eventually, your
dev system will be ready to test/test/test/document/amend user guides.
Then move it to production.
Then start on the next version and implement all the user
requests/changes you've collected since the last "freeze". The cycle
repeats.
Tom Krieg
Larry DiGiovanni
Tom Krieg wrote:
> Eventually, your dev system will be ready to test/test/test/document/amend
> user guides. Then move it to production.
I consider three environments a minimum: dev/test/prod. The testing
environment provides an opportunity to not only test the software
modifications, but also the deployment, so you don't find out in production
that you forgot to migrate some key artifact from development.
--
Larry DiGiovanni
Digico, Inc.
IT Consulting and Staffing Solutions
www.digicoinc.com
Check out www.thedbcommunity.com for Paradox resources.
Peter Rousseau
Aahh, now I get it. It's virtually impossible to keep tables/data models and form
changes all in sync as well as keep archives/backup. So the idea is to
backup/archive the whole project when the specs have been met (and remember to
document the progress). There would be a lot of backups. Do you overwrite previous
ones or just keep adding to the others in the backup directory. Also, do you zip
'em up?
This really helps a lot, thanks.
Peter R
Tom Krieg
I'd keep at least the last 3 development backups (grandfather/father/son
system). Have your development system in the one directory
(sub-directories for forms, libraries, tables etc etc) then just zip up
your master dev directory (if you use Windows backup you may find it's
changed in a new version and you can't use the old backup files). I
backup unzipped to CD regularly and keep all my CD backups (just in case).
****ALWAYS**** keep at least 2 copies of your latest production system
on CD's, together with good, clean copies of all your tables (empty) so
you can recover tables if necessary from .db file. Backup your
production tables every day/night. Zipping these up is OK (Pdox tables
zip really well).
Ken Loomis
On Wed, 6 Oct 2004 20:37:54 -0400, "Larry DiGiovanni" <nospam@nospam>
wrote:
>
>I consider three environments a minimum: dev/test/prod. The testing
>environment provides an opportunity to not only test the software
>modifications, but also the deployment, so you don't find out in production
>that you forgot to migrate some key artifact from development.
I second Larry's recommendation. In addition, since your production
environment consists usually of delivered forms, a "stage" environment
that has the un-delivered forms and reports is necessary. It is from
the stage environment that you build your delivered files. I
sometimes combine the test and stage environments, often with regret.
It take discipline not to make changes directly in the stage..
The biggest challenge I find is to test changes, particularly fixes,
thoroughly when under time pressure. It's easy enough to test the
change or fix itself, it's another thing to test the entire system for
the unintended consequences of the change.
For this reason, it's a good idea to develop a suite of test cases
that run through the entire system. This in itself is a major effort
and one that's hard to sell on the outset of a project. There are
sophisticated programs that run tests on other development
environments. I know of none for Paradox.
Ken
Tom Krieg
Ken Loomis wrote:
I've got 2 customers that do that for me <g> I test until I get no
errors, then pass the system on to these 2 guys who ***will*** break it
if it can be broken. When they can't break it, I know it's tested.
Tom K
-Ping-
Peter,
all time i've done something with a form, i save it, and save it with
YearMonthDayHourMinute in front of the name, after this i open the
original form.
If there are any changes at tables, I use 7Z to make a zip of database,
for this download 7Z at www.7-zip.org, its free and able to genarate
*.zip files if needed, copy 7z.exe to WinDir and use a form with a
button like this:
method pushButton(var eventInfo Event)
var
winNames Array[] String
Element longint
ts textstream
yi,moi,di smallint
hi,mii smallint
s,s1 string
endvar
enumDesktopWindowNames(winNames)
; Schreibt Fensternamen in ein Array.
for Element from 2 to winNames.size()
if not (winNames[Element]="Programmpool") then
;my form Programmpool has it's own exitprocedure
f.attach(winNames[Element])
f.close()
endif
endFor
exit() ; no locks on tables
sleep()
s1=workingDir()
s1=s1.substr(4,s1.size()-3)
;............ Datum ermitteln ......................................
yi=year(today())
moi=month(today())
di=day(today())
hi=hour(time())
mii=minute(time())
s="c:\\backup\\"
;Jahr:
s=s+string(yi)
;Monat:
if moi<10 then
s=s+"0"+string(moi)
else
s=s+string(moi)
endif
;Tag
if di<10 then
s=s+"0"
endif
s=s+string(di)
;Stunde:
if hi<10 then
s=s+"0"
endif
s=s+string(hi)
;Minute:
if mii<10 then
s=s+"0"
endif
s=s+string(mii)+"_Kunden-Viewer.7z"
;in s liegt nun der Name für das archiv
;Batch erzeugen auf Desktop:
ts.create("c:\\backup\\7z.bat")
ts.writeline("D:") ;my data - HDD
ts.writeline("cd\\")
ts.writeLine("7za.exe a "+s+" "+s1+"\\* -r")
;ts.writeline("Pause")
ts.close()
execute("c:\\backup\\7z.bat",No)
endMethod
HTH
-_Ping-_ (Günter Matthies, Ludwigshafen, Germany)
Ken Loomis
On Fri, 08 Oct 2004 16:20:00 +1000, Tom Krieg <info...@aanet.com.au>
wrote:
>I've got 2 customers that do that for me <g> I test until I get no
>errors, then pass the system on to these 2 guys who ***will*** break it
>if it can be broken. When they can't break it, I know it's tested.
I know the drill. They just have to be understanding, loyal
customers. :-)
Ken
Larry DiGiovanni
Tom Krieg wrote:
> When they can't break it, I know it's tested.
That's known as the "monkey-clicking" test plan. <g>
--
Larry DiGiovanni
Digico, Inc