Combined with git-appraise, a code review tool that stores review requests and metadata in the repository itself, this could be a solution for “completely secure” team software engineering.
Has anyone used git-appraise with their team? I’ve wanted to give it a try but haven’t really found a reason or team willing to try it out.
One could imagine that keybase is watching this space and is evaluating the possibilities of integrating this, or something like it. A git-appraise UI in the app, perhaps?
The compliance story is really strong here. Verified pushes, verified sign-offs! Exciting!
I work at keybase (https://keybase.io/patrick) and will pass along the suggestion…thanks!
You should get a keybase hat!
I’m biased, but I genuinely think FogBugz is excellent at these. The email workflow rivals customer management software I’ve used, with customer aggregation, trivial elevation, ability to track case status through a webpage if desired, and full email-based workflow for customers (they barely even need to know they’re actually interesting with FogBugz), and you get all the other FogBugz stuff too (wiki, EBS, discussion forums, etc.). Plus it’s free for the first two users (i.e. employees who use it, not customers).
So if there’s just one employee that uses it, it’s completely free?
Yep; the whole thing is free for dev teams up to two people. You can read more details (and get a free account) at http://www.fogcreek.com/fogbugz/StudentAndStartup.html .
github issues seems to work fine, and it’s really convenient if you’re already using github
GitHub issues doesn’t do email-based support, and it requires your customers to have GitHub accounts to report bugs. That’s fine if you’re doing a random open-source project, or if you have an external system to handle the customer management side, but it’s otherwise not an acceptable bug tracker.
I think a lot of people upvote GitHub due to familiarity, but as a bug tracking system it’s pretty crappy compared to “real” bug tracking software.
Yeah, that’s pretty much a deal-breaker (forcing customers to have github accounts). Thanks for pointing that out.
The whole article seems to hinge on a message broker as a single point of failure. I personally haven’t used a broker with that flaw in years.
Even brokers like RabbitMQ are hard to configure to guarantee reliability and durability. Also, in those configurations, performance is greatly impacted.
What about SQS?
SQS is easier, but has a big problem: for many enterprises, it is out of the question due to being off-premises. For me, working in such an enterprise, we must always look for self-hosted solutions. Even if SQS is configured correctly, the fundamental performance bottlenecks/issues still stand.
For an SOA, a broker introduces an SPOF that every message must route through. A better design is what amontalenti said below: a peer-to-peer connection system. I would additionally argument that an RPC mechanism like HTTP, combined with idempotent RPC actions and automatic retries, is even more robust than peer-to-peer queuing.
Russ Cox responded on the golang mailing list about this: