Working under Team Coding and version control:
I was modifying code for a change and had to set the task aside for a couple of days. But then I didn’t know where to save my in-process changes? Since the code wasn’t ready to re-compile, I tried saving it directly into to the local repository without compiling but Team Coding/Git kept putting it back to the “live” version of the code. How does TOAD envision the workflow under version control when a change mighty take several days?
Hey Douglas,
This would depend on each person’s personal preference. The database, itself, has no concept of creating branches or shelving changes for work-in-progress. As a result, as you know, Team Coding is designed to work directly in the trunk synchronizing the VCS with compiled DDL in the database. Since most environments have separate systems (dev, qa, prod), it would be very common that the dev environment can, and will, most likely contain code that’s only partially finished.
If I’m understanding you correctly, what you’re describing, however, is work that hasn’t yet been compiled into the database but is currently a work in progress. I’m assuming they’re most likely changes you’re making in the editor but haven’t yet pressed F9 to compile them into the database. In the dev environment, some people would simply compile what they have into the database and leave the object checked out so it isn’t modified by another user. Others might undo the checkout and revert their changes in the database opting to save their modified DDL to a script somewhere temporary on the hard drive (and outside VCS). You generally would not want the files in the VCS to be updated with non-database code as Team Coding will then see the VCS and Database source as “out of sync” and report on the DDL differences when you attempt to check the object out next time (if you have that option set).
If it were me, and I expected no one else would need access to the objects on which I’m working, I would disable the “Check in All on exit” local option in my Team Coding settings, leave the object checked out, and save the modified DDL to an external file for continuation later. The checked out object reminds me that it’s outstanding, but my changes aren’t in the database until they’re ready. If I thought someone else might need access to that object for another project, I would probably save my DDL changes to an external file and then undo the checkout to release the lock. That way, I’m not hindering another member on the team. When I’m ready to revisit the object, I’d probably open my work file in one editor tab, the object’s DDL in a second editor tab, and then right-click on one tab and select “Compare To” and select the other tab. That will open up both’s source in the Compare window so I can see the changes between the two in order to continue my work.
Does this help to answer your question?
-John
Thanks John, You continue to add insights on making this work. Sometimes they make my head ache :\ but I’d rather deal with them now instead of later when we’re live!
Using check-out status as a reminder of unfinished code could work. I’d rather have all it somehow safely ensconced in version control but, as you say,…
Can we put the whole thing together somehow? Here’s an example work effort for us. (FWIW, as I’ve said other places, we’re a small team supporting our in-house systems which are dominated by our academic ERP system). Can you walk me through what I should do and what team coding and version control will be doing? Some areas of uncertainty are table DDL vs table ALTERS, conversion scripts, and the whole deployment thing, like, is our VCS “trunk” Test or is it PROD? If its TEST, then when/how do we “move” changes to “production”, VCS speaking, and Oracle speaking?
Hypothetical Request Ticket: Add Total Credits to the Student History Table
Programming - That ticket would generate the following work effort
a. Add total_credits column to student_history table (note: be sure to retain existing data)
b. Update student_records package (note: several functions reference the student history table so each function will have to be modified and tested)
c. Update the nightly script which the auto-scheduler runs to populate student history from daily_student
d. Update daily_student materialized view (source of total credits by student by day, used by several apps)
e. Update daily_student materialized view query (to include retrieval of total_credits)
f. Create and test scripts to populate existing student_history records with historic total credits data
Deployment - Currently version control is not part of the flow so, pretty standard handover
a. Create a change request packet which includes the required ToDo steps and a recovery plan if the change fails
b. Submit the change request for review and approval
c. Upon approval, Change Control deploys the changes to production