Best practices on check-in-ing vs deliverin?
Hi!
RTC has two basic concepts of checkin and delivering. If you're making a checkin, you're basically saving your local changes to your remote repository on the server, that is saving changes into a changeset saved on server. If you're making a deliver, you're delivering those changesets to a stream.
My question is related to how often should a developer make the deliver operation. In my company, people are used to make deliveries often, even though the functionality they're working on isn't complete. A lot of trash is delivered and sometimes deliveries break the applications. I'm being pointed as someone extremely strict for not allowing deliveries without code review, but I'm really not sure if that is the case. Another point is, when you deliver often, it expands the change history graph making life harder to pin point specific working versions.
How do you manage that?
|
One answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Sep 30 '18, 6:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER When you should deliver to a given stream depends entirely on the "quality level" that you have defined for that stream. The most common minimal quality level is "the change compiles". A higher quality level is "personal build of type X completes successfully" (where "type X" determines the quality level). Another quality level is "work item must be approved by a specified set of approvers". In general, you should deliver as soon as you have reached the specified quality level of that stream, to minimize merging.
How frequently you should try to reach the specified quality level is a tradeoff ... on one hand, the more often you reach that quality level, the less merging there is ... on the other hand, the time spent reaching that quality level decreases the amount of time you can spend doing new coding.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.