...
...
...
...
| Table of Contents | ||||
|---|---|---|---|---|
|
Overview
| Excerpt |
|---|
Now that we are in production our processes for pushing code out to any instance beyond TST is going to change for a short while. Pam, Geoff, and I talked about it yesterday but we could use your help in making this change easier. They would like the ability to choose which mods and bug fixes go into production and which stay in TST. There will be more merging now because of this. I know we all have our different SVN check in styles and habits, and normally I wouldn't have a problem with it, but because they want to choose what goes and what stays I am going to request that we all follow 2 simple rules for a little bit especially if you are checking anything into the trunk. |
Process
Code Commits
- Comments should begin with the JIRA ID. No more then one JIRA per check in. We run into a problem with this if they want one fix but not the other.
- Try and keep your JIRAs to as few checks in as possible, one would be ideal. I understand some of you like to check in each file separately in order to add a different comment to each file, but at least for now could you please just check them all in together and then in the SVN comment you can list the files and why they were modified. The more check ins there are the more likely it is that something will be missed.Since you are limiting your checkins, you also only want to work on one Jira issue at a time. If you work on 2, it is possible you will check in some code from both when you finish only one. This is especially the case when you are working on 2 issues in the same module that may touch the same files (constants for example).
Use Cases
1 How Do I Work on 2 Jira Issues at One Time "Stashing"
...
- .