5 ms·

If the unit tests pass, it's safe to commit.

by flatline3 14y ago

philwelch 14y ago
Are you being facetious?
- flatline3 14y ago
  Honestly, no. This is how we work in a combined mainline branch while only using feature branches for relatively rare work that extends beyond a single subsystem and would break other people. By and large we can keep mainline in a stable and releasable state, which has some advantages in terms of forcing people to take care and keep their code clean as they work. For stable releases, we just peel off a release branch and stabilize there. The fewer branches we have, the simpler it is to keep track of everything.
  - philwelch 14y ago
    Oh, you're just talking about the central repo server. Yeah, I wouldn't push feature branches to origin either, but I definitely still have them locally. They end up rebased, squashed, fast-forward merged, and pushed only to the mainline anyway, so no one need be the wiser. But "if the unit tests pass, it's safe to commit" is a very...questionable sentiment. It makes sense if you do release branches, and if you have very good test coverage, and if there isn't a lot of tricky stuff that's hard to capture in unit tests--that's just is a combination I've yet to encounter and largely consider to be mythical. I'd love to be proved wrong on that point. I wonder, where in your process does code review come in?
    - flatline3 14y ago
      > Oh, you're just talking about the central repo server. Yeah, I wouldn't push feature branches to origin either, but I definitely still have them locally. They end up rebased, squashed, fast-forward merged, and pushed only to the mainline anyway, so no one need be the wiser. We actually use SVN. It is considered negatively impacting on communication to have work hidden on local DVCS branches instead of immediately visible to the team upon commit. This requires one to commit often, in very small chunks, while driving from a test-first perspective. In the cases where that isn't possibly (highly experimental work), a branch will be used. > But "if the unit tests pass, it's safe to commit" is a very...questionable sentiment. It makes sense if you do release branches, and if you have very good test coverage, and if there isn't a lot of tricky stuff that's hard to capture in unit tests--that's just is a combination I've yet to encounter and largely consider to be mythical. I'd love to be proved wrong on that point. Inadequate unit test coverage or missing documentation would be considered a serious offense here. The only code that winds up being difficult to capture in unit tests is usually GUI code (or in the case of web development, the HTML/CSS front-end bits). The testing and validation of those pieces happens outside this process, usually driven by basic automated integration testing and the watchful eye of the design department. The UI code is expected to be minimal and only involved in the UI. All significant work occurs in the testable backend code. > I wonder, where in your process does code review come in? After commit, diffs on the mailing list are reviewed, but not formally. If someone thinks something needs another set of eyes, they ask explicitly.

If the unit tests pass, it's safe to commit.

philwelch 14y ago

Are you being facetious?

flatline3 14y ago
Honestly, no. This is how we work in a combined mainline branch while only using feature branches for relatively rare work that extends beyond a single subsystem and would break other people. By and large we can keep mainline in a stable and releasable state, which has some advantages in terms of forcing people to take care and keep their code clean as they work. For stable releases, we just peel off a release branch and stabilize there. The fewer branches we have, the simpler it is to keep track of everything.
- philwelch 14y ago
  Oh, you're just talking about the central repo server. Yeah, I wouldn't push feature branches to origin either, but I definitely still have them locally. They end up rebased, squashed, fast-forward merged, and pushed only to the mainline anyway, so no one need be the wiser. But "if the unit tests pass, it's safe to commit" is a very...questionable sentiment. It makes sense if you do release branches, and if you have very good test coverage, and if there isn't a lot of tricky stuff that's hard to capture in unit tests--that's just is a combination I've yet to encounter and largely consider to be mythical. I'd love to be proved wrong on that point. I wonder, where in your process does code review come in?
  - flatline3 14y ago
    > Oh, you're just talking about the central repo server. Yeah, I wouldn't push feature branches to origin either, but I definitely still have them locally. They end up rebased, squashed, fast-forward merged, and pushed only to the mainline anyway, so no one need be the wiser. We actually use SVN. It is considered negatively impacting on communication to have work hidden on local DVCS branches instead of immediately visible to the team upon commit. This requires one to commit often, in very small chunks, while driving from a test-first perspective. In the cases where that isn't possibly (highly experimental work), a branch will be used. > But "if the unit tests pass, it's safe to commit" is a very...questionable sentiment. It makes sense if you do release branches, and if you have very good test coverage, and if there isn't a lot of tricky stuff that's hard to capture in unit tests--that's just is a combination I've yet to encounter and largely consider to be mythical. I'd love to be proved wrong on that point. Inadequate unit test coverage or missing documentation would be considered a serious offense here. The only code that winds up being difficult to capture in unit tests is usually GUI code (or in the case of web development, the HTML/CSS front-end bits). The testing and validation of those pieces happens outside this process, usually driven by basic automated integration testing and the watchful eye of the design department. The UI code is expected to be minimal and only involved in the UI. All significant work occurs in the testable backend code. > I wonder, where in your process does code review come in? After commit, diffs on the mailing list are reviewed, but not formally. If someone thinks something needs another set of eyes, they ask explicitly.