GlassFish Workspace Check-in Best Practice 1. svn update and do a full build from top level. 2. If you are integrating external modules to workspace:
- make sure there are no SNAPSHOT dependencies
- the artifact exists in the remote Maven repository
- remove the artifact in your local Maven repository and do a complete build
3. If you add/update a pom.xml, you need to get approval from the RE team. Send an e-mail to the dev. alias requesting approval. 4. Run QL tests. If your changes do not impact glassfish profile, then run the QL web profile. If your changes impact both web and glassfish, run both QL on both web and glassfish profiles. QL Instructions 5. If your code is extensive (non-trivial), please have it reviewed by the module lead. 6. If you are adding new modules in the workspace or external module dependencies, please have it reviewed by the packager lead. 7. Do another svn update and make sure there are no conflicts right before committing. If Hudson jobs are failing (see step #9), please refrain from committing until Hudson is back to normal. 8. Commit the change using an well written commit message (see below). 9. After commit, monitor the following Hudson jobs:
10. If QL does not test your new code, please contact QA lead about adding new test cases in QL. Commit Messages The commit message becomes part of the permanent record of the change in the source code repository. These messages are available to any developer using the "svn log" command and are shown in the "recent changes" section of Hudson jobs. Good commit messages can greatly enhance the ability to review past changes to the code. What questions does a person want to be able to answer by looking at the commit messages, and what does that in turn imply about what must be included?
- Why was this change made? Formal bug identifier? Feature requirement? FindBugs fix? Copyright date correction? We can't link every check-in - not today at least - to a JIRA or another issue tracking system. When we can we should and when we can't the commit message should briefly describe the problem being fixed or the improvement being made.
- What's the general thought behind the solution or improvement?
- Who reviewed or approved the check-in?
- What tests did the engineer run before check-in? (Can in a few cases be empty - for example, when updating a copyright date or a comment)
For problems, the combination of the formal issue and the commit message should explain:
- the outward bad behavior. (Typically, if there is an issue, then this should be in the issue.)
- the underlying cause, (In either the issue or the commit message - some people like to report their fact-finding in the issue as they work through it, some save it for the commit message), and
- the repair. (in the commit message).
So given this, here is a template to use when writing commit messages:
<issue-id or "no issue"> - <summary of change>.
[Approved/reviewed by <name>.]
[Passed <list of test suites>.]
The bugid should be something like GLASSFISH-12345, not a URL. Typically only one issue should be fixed in a commit, but if multiple issues are fixed, then use a separate line with a separate summary for each issue. The summary of change may be multiple lines, especially if there is no issue. This summary must at least include a high level description of the changes that were made. If there is no issue, then this may also include a description of what problem is fixed by the change. The name should be the person's real name. The list of test suites can use commonly known abbreviations like QL for Quicklook. The "approved" and "passed" lines are optional but recommended. Here is an example commit message that uses this template.
GLASSFISH-20056 - Get the deployment order out of the map as a separate step
before constructing the ApplicationOrderInfo. Also check if the application
is already loaded before trying to load it in InstallerThread.
Passed QL, deployment dev tests.
When using the -m option of the svn commit command, it is fine to put all of this information on one line. |
