Using Visual Studio Online, how should we mark bugs that are not reproducible? I don't want to mark them as "Done", obviously. Marking them as "Removed" feels weird, but maybe that's the correct way to handle them. Any advice?
This is exactly the kind of thing you can solve with tags. You're not fixing the bug -- the reason doesn't matter. It's "Done". Then tag it as "No-Repro", and you have a way to track it.
As Bugs are the result os a failing Test Case you should not have any Bugs that are not reproducible. It's about workflow.
When a user reports issue should a tester to use exploratory trying tools to verify that it is indeed a bug.
At that point they can create both the Bug and related Test Case that proves that it exists.
Ultimately you should never have a bug in your system that does not have a Test Case associated.
If you don't have that workflow then you can use Tags as Daniel suggests, but changing your workflow would be a better option. Less rework...
Related
I was wondering if you know any tools that help keep track of "code smells". So that team members could report some finding in the code and then possibly vote on the most problematic ones (in terms of future project development).
Any experiences?
Have you looked at find bugs or check style? Both of these are pretty good for this.
I would also recommend pmd. These let you analyse common problems such as not setting method parameters final.
Lastly, I'd recommend using Sonar as this will highlight any code errors in order of priority. Such as code that is knowingly going to through a NPE, it will highlight this to you and can be integrated with Jenkins.
All these together can really help you move towards the "Clean Code" mantra.
How do you use Xcode's Extract refactoring tool?
Whatever code I select, I always get the same unhelpful error message.
The selection does not contain anything that can be extracted. Make a
different selection and try again.
See the screenshots below:
What do I need to follow to have it work?
I am doing this on a simple iOS project, nothing special, no C++. Tried with the latest version of Xcode (4.4) and the newer latest developer preview releases.
Is this a bug? Any workaround?
For some strange reason if you have a block that doesn't create an obvious return value of pick up parameters XCode complains if you include the newlines. In my opinion this is a bug, as whitespace should be ignore. Just make sure you don't include the newlines. For example, the following works with "Refactor > Extract Method":
Automated refactoring tools first check that certain preconditions are true before applying the requested refactoring. In this case, it seems that the preconditions failed. I've done plenty of similar Extract Method refactorings in XCode and I can't why there's a problem with the code you selected. Perhaps there's some subtle dependency that isn't apparent in the code you show.
I'm not sure if I'd call this a bug. In developing a refactoring tool the developer can always make the preconditions a bit weaker at the price of more complicated refactoring logic.
Doesn't solve your problem but perhaps is of some help.
I regularly see production code from developers (large companies and individuals) that contains code that has been commented out. Presumably this removes earlier attempts at achieving the functionality that didn't work for some reason.
To my mind, this is messy, but potentially has some benefits e.g. on returning to refactor or extend the code, the developer can see what has been tried previously.
Are there any security or best-practice aspects to this?
Best practice is to use SCM. If you think the old code is really something people will want to refer to in the future, leave a comment of "// We used to do it another way, which had interesting property X -- see revision 103" rather than leaving whole chunks of code that don't do anything.
Commenting out code has its place, but that place is quickie tests that aren't even worth the time to do a branch.
If the code is worth keeping, it's worth more than being lost in a comment somewhere. If it is not worth keeping, kill it with fire.
Code should be stored in source control.
Comments should be reserved to explain difficult to understand code or the reason for doing something out of the ordinary.
Best practice is that your code shows only the current. You should be using an SCM that deals with code history.
We are working in a CI environment, with Enterprise Cruise running our builds. Developers all have CCTray installed locally to notify us if a build breaks.
CCTray has a menu option Volunteer to fix build that you can use to let your team know that you are fixing the build. However this doesn't work in our environment (reasons: Fix build not currently supported on projects monitored via HTTP).
So the question is - does anyone have a technique that they use in their team that allows someone to indicate that they are fixing a broken build?
For me, Continuous Integration is not only about tools, but also about practices. One of them is the responsibility. In others words, the one who breaks the build is also the one who will fix it!
Shooting "I take it guys" is my prefered. ( in addition of the responsability romaintaz describe )
We send an email to the Developer's mailing list to let everyone know you are taking ownership of the build break.
We're co-located, we all run cctray, and when the build breaks we have an audio alert (red alert from the Starship Enterprise). When it breaks we all shout "who broke the build"! Once we figure out who broke the build we harhass them until they tuck their tail between there legs, do that stupid embarassed laugh, and volunteer to fix the build.
It's worth noting that things that aren't monitored by the build and tests can change on a CI box. For example: maybe someone went onto the box and changed a permission. Then when the next checkin is made it looks like the person that made the checkin broke the build when really it was the person that made the manual change without telling anyone.
On the volunteer thing, tools can help but verbal face to face communication is still king.
The onus is usually on who broke the build with their checkin. That's often obvious, even with multiple checkins from different individuals. After that there's a bit of negotiation if the build remains broken. Not particularly scientific or rigorous, but it seems to work.
If the build brokes, then in CCtray there is an option for "Volunteer to fix the build".
And it tells automatically to all the developers who is fixing the build
I use cruisecontrol.rb for CI and FogBugz for bug tracking, but the more general the answers, the better.
First is the technical problem: is there an API for FogBugz? Are there good tutorials, or better yet, pre-written code?
Second is the procedural problem: what, exactly, should the CI put in the bug tracker when the build breaks? Perhaps:
Title: "#{last committer} broke the build!"
Body: "#{ error traces }"
I suppose this presupposes the answer to this question: should I even put CI breaks into my bug tracking?
At my company we've recently adopted the (commercial) Atlassian stack - including JIRA for issue tracking and Bamboo for builds. Much like the Microsoft world (I'm guessing - we're a Java shop), if you get all your products from a single vendor you get the bonus of tight integration.
For an example of how they've done interoperability, view their interoperability page.
Enough shilling. Generally speaking, I can summarize their general approach as:
Create issues in your bug tracker (ex: issue key of PROJ-123).
When you commit code, add "PROJ-123" to your commit comment to indicate what bug this code change fixes.
When your CI server checks out the code, scan the commit comments of the diffs. Record any strings matching the regex of your issue keys.
When the build completes, generate a report of what issue keys were found.
Specifically to your second problem:
Your CI doesn't doesn't have to put anything into your bug tracker. Bamboo doesn't put anything into JIRA. Instead, the Atlassian folks have provided a plugin to JIRA that will make a remote api call into Bamboo, asking the question "Bamboo, to what builds am I (a JIRA issue) related?". This is probably best explained with a screenshot.
All the CI setups I've worked with send an email (to a list), but if you did want—especially if your team uses FogBugz much as a todo system—you could just open a case in FogBugz 6. It has an API that lets you open cases. For that matter, you could just configure it to send the email to your FogBugz' email submission address, but the API might let you do more, like assign the case to the last committer.
Brian's answer suggests to me, if your CI finds a failure in a commit that had a case number, you might even just reopen the existing case. Like codifying a case field for every little thing, though, there's a point where the CI automation could be "too smart," get it wrong, and just be annoying. Opening a new case could be plenty.
And thanks: this makes me wonder if I should try integrating our Chimps setup with our FogBugz!
CC comes with a utility that warns you when builds fail, it probably isn't worth logging the failing build in FogBugz - you don't need to track issues that are immediately resolved (as most broken builds will be)
To go the other way round (FogBugz showing checkins that fixed the issue) you need a web based repository browser - FogBugz is easy to configure so that it shows the right changes.