Archive for the ‘FogBugz’ Category

Sign Up For the FogBugz Beta!

March 26th, 2013 by Aaron Maenpaa

Want to see what’s coming in the next version of FogBugz? Now you can! The FogBugz team has been hard at work on a project we’ve code-named ”Ocelot” for the past several months. We’ve rebuilt the core pages of FogBugz to use a completely new architecture that’s significantly faster. Like, seriously fast. And now we’re ready to start sharing it with you!

 

What’s shiny and new?

The new version of FogBugz is a single page app when it comes to the list page and the case page. What’s that mean exactly?

  • a super fast list page for listing and filtering your cases
  • a wicked fast case page for viewing and editing individual cases
  • blazing fast search for finding the cases you’re interested in
  • and blink-of-an-eye fast transitions between these pages

We’ve been dogfooding the new UI internally for a couple of months now and it has really improved our own experience of using FogBugz. We hope you’ll like it!

Riding the Ocelot

 

A Word of Caution

This is a beta, so there will be bugs. If you find one, please contact our customer service team and let them know. Furthermore, since we’re trying to get this into your hands as soon as is humanly possible, there are some caveats to the beta:

  • The beta is for FogBugz On Demand accounts only.
  • The beta UI has only been tested in Firefox and Chrome. Support for IE10 and Safari are on our TODO list and they should mostly work, but they might not and you will probably run into cosmetic issues.
  • Customizations from the BugMonkey Plugin will not apply to the beta UI.
  • With a few exceptions, existing plugins will not interact with the beta UI.
  • A number of features have not yet been implemented including:
    • Custom fields
    • Quick case add on the list page
    • Graceful handling of concurrent case editing
    • Similar speed improvements and single-page-appification to Wikis, Discussion Groups, Reporting, Admin pages, etc.
    • The Working On menu
    • Searching Wiki Pages and Discussion Groups from the main search box
  • With the exception of some specific text used in outgoing emails, the beta UI is not localized

 

Share your Feedback

We’re looking for feedback on: How the application feels, your general impressions, any missing features that impact your day-to-day workflow, and of course any bugs you find. Once you’ve started using the beta, please contact our customer service team and let them know what you think!

Once your account is enabled for the FogBugz Beta, you can enable and disable the beta UI on a per user basis from a link in the top right corner. If you later decide that you’d like your entire account taken off of the Beta, just let us know and we’ll be happy to take care of that for you.

 

Sign Up!








Dogfooding Until It Hurts

February 26th, 2013 by Rich Armstrong

Dogfooding. Also called “eating your own dog food.” It’s pretty simple, right? If you work at Uber, maybe take an Uber car ride from time to time. If you work at Khan Academy, you’re probably pretty good at math by now.

In this video from 2009, Joel talks about dogfooding as being more than just using your own product. It’s about using your own product for everything you can imagine, even if that usage is a little uncomfortable.

We dogfood Trello, FogBugz, and Kiln in a ton of different ways.

We’re a software company, so we generate a lot of code. Kiln helps with that. But we even use it to hold things that aren’t “code” per se, such as backups of non-sensitive databases. We don’t have any real crazy use cases, like using code reviews to plan parties or the electric DAG to create subway maps, but that’s just because Kiln has only been around a few years.

FogBugz, on the other hand, we use for tons of off-label stuff. We use FogBugz’s crash reporting ability to read RSS and Twitter feeds and create cases when new items appear. We use its customer email capabilities to receive faxes. And we have a panoply of API scripts automating a bunch of different business processes.

Trello is a natural for dogfooding, of course, because it’s so flexible. We keep kitchen snack requests and lunch menus on boards. We keep track of who’s going to what conferences, and use it to plan their travel. Trello really shines in setting the agenda for and running our bi-weekly company all-hands meeting. Because Trello is so flexible, it invites a lot of different use cases. We’re still figuring out which ones really work, and it’s great to see a fast-growing user base figuring that out alongside us.

So, that’s all well and good, but if you really want to see “dogfooding until it hurts” in action, check out Beeminder, a tool for setting “goals with a sting.” You set up your goals, and if you stray from them, the service fines you an escalating amount of real money until you’re back on track. Beeminder is dogfooding heavily and publicly to keep their development goals on track. These folks are  literally giving away cold hard cash to users as a pre-commitment to do things like delivering user-visible enhancements or blog posts on a regular basis. Amazing. Even better, they have a Trello integration that’ll keep you moving those cards to the Done column regularly (or else).

 

BugzScout: Simple Free Crash Reporting

February 11th, 2013 by Rich Armstrong

BugzScout helps you improve software quality by aggregating stack traces under the version, file and line they occurred on.  Here’s Joel and Tyler explaining it a few years back.

 

 

BugzScout certainly isn’t the only crash reporting solution out there. It’s not even the most full-featured (and, shhhh, that’s often why we like it). Crashlytics is a good one. Airbrake has traction in the Rails community. For mobile app development, we’ve found Crittercism invaluable. But BugzScout is simple and flexible, comes free with FogBugz and Kiln, and actually has many uses beyond crash reporting. (We use it as an RSS feed reader! Ping us to learn how.) No matter how many times the crash occurs, only a single case is created. It’s much more civilized than, say, flooding your inbox with a zillion dupe crash reports.

Have FogBugz and want help implementing BugzScout for your project? There’s a BugzScout section in our online webinar. Or, if you need personalized help, let us know!

Interested in making your software better through crash reporting, but don’t have FogBugz? Start a trial and get in touch!

At Long Last: The Case Merge Plugin!

August 30th, 2012 by Quentin Schroeder

We have a variety of methods for tracking what features our users are looking for, and by every measurement available, the ability to Merge Cases was at the top of the list! In fact, this has been a top feature request for quite some time.

We’ve had our eyes on this feature for a while now and even drafted a feature specification for it, but while we were drafting ideas, a user from the FogBugz Developer Community contacted us with a fully functional plugin that solved the problem! So, without further ado, may I present the Case Event Merge Plugin, written and generously shared by the developers at Quarantainenet:

“The FogBugz Case Event Merge plugin adds the functionality to display the case events of a duplicate case in the original case…. We have tried to overcome the design problem of merging by not merging at all: we just display the events of one case in the history of the other, keeping the workflow of cases intact.”

Here’s a quick video that goes over how it works:

The Case Event Merge Plugin is available for both FogBugz On Demand and customers running FogBugz on their own server. Follow the installation instructions to get started, and check out the full documentation to see what the authors have to say about it. Read on for a bit of history on the development of this plugin.

 

Why was this feature so hard to add?

After Quarantainenet knocked the ball out of the park with this plugin, it is easy to look at it and wonder why Fog Creek didn’t deliver it earlier. The answer lies in the details, or to be more accurate, the lack of details.

The solution that Quarantainenet devised is simple because it does not manipulate the existing rows in the database. In the feature specification draft that we were working on at FogCreek for merging cases, we were looking at it from the opposite perspective and dealing with the repercussions of trying to move the bug events from one case to the other within the database. In this scenario we had a lot of corner cases and questions that weren’t trivial to deal with.

For example:

  • Once a case is merged to another, does the system delete it?
  • What happens with new incoming emails that have the case number for the now-closed duplicate case?
  • Do we try to merge the attributes of the two cases together?
  • How do you seamlessly transition the conversation to the new case and discourage updates to the old one?

Each of these questions has valid possible solutions that we considered, but would lock the users into a specific workflow, which was something we were trying to avoid. The ability to merge cases had to make life easier for users who kept getting emails with the Case keyword stripped from it, or those infamous CC chains that seem to spawn an endless number of new cases. The solutions we were batting around made life easier in about eight out of ten scenarios, but made life a lot more confusing in those last two cases. The net gain was teetering on the edge of positive, which meant producing it just wasn’t worthwhile.

 

A Fresh Approach

The genius of the Case Event Merge Plugin is that the only data it requires is a marker for the duplicate cases whose events we want to display in the other case. The real work comes when FogBugz goes to render a case view page; the plugin interacts with the rendering process and creates a bunch of “pseudo bug events” from the duplicate cases. (The Kiln plugin uses the same pseudo bug event mechanism to show changesets inline with the rest of the case). These events are read from the database just as they would be if the user went to view the closed duplicate case. What this means is that the Plugin can crash, fail, be deleted, mucked with and otherwise abused and your original data is left completely intact.

Because Quarantainenet was never thinking about manipulating the existing Bug and BugEvent tables, their solution exclusively utilizes the rendering of the case view. This means that all of the core FogBugz code gets to keep chugging happily along, completely oblivious to the fact that these two cases are anything but “Resolved as Duplicates”! It’s simple, elegant, and it just works.

This plugin is already being used heavily at Fog Creek and we know many of our customers are excited about its release as well. Several years after the feature request first appeared, we’re glad that we can finally mark it as Resolved (Implemented).

Source-Control-Like Comments for Timesheet Intervals in FogBugz

April 18th, 2012 by Adam Wishneusky

As a support engineer here at Fog Creek, I get to play around pretending to be a programmer sometimes, mostly to help customers with Plugin and XML API codez. I recently collaborated with an intrepid FogBugz user to create this plugin which allows you to put a comment on each time interval. It adds a [comment] link in the timesheet editor:

timesheet editor

When you click it, you can enter a comment in a new dialog:

comment dialog

which then shows up in in the editor:

timesheet editor with new comment

The plugin uses some javascript hackery to modify the timesheet editor since there is no plugin interface to implement to change its functionality. As such, it works with FogBugz 8.7 and is not tested and approved for FogBugz On Demand. You can download the plugin to run on your own local FogBugz server, and get the source code from my post here on the FogBugz Knowledge Exchange.

Better BugzScout Error Reporting

January 30th, 2012 by Jude Allred

Prelude and a pain point.

One of the many ways to spawn cases in FogBugz is via a mechanism we call BugzScout. BugzScout is a simple interface for collecting crash reports from your software in the wild. For example, you might add an exception handler to your product which hooks into BugzScout so that when your customers encounter errors, you receive a case in FogBugz with details about the problem. Unlike the FogBugz XML API, which can also be used to serve this use case, BugzScout doesn’t require that you embed any type of FogBugz security token in your deployed application, and BugzScout will automatically collate all of the bug reports into cases based on titles of the reports.

We use BugzScout extensively throughout our own infrastructure — when FogBugz accounts misbehave, if an unparseable email gets stuck in an account’s mail queue, if an account’s full-text search index gets corrupted, etc., we receive cases in our FogBugz environment detailing the problem and often including key diagnostic information such as stack traces and assorted report-specific meta-data.

BugzScout has been around for a while, long enough to get a little crufty, and we’ve felt some BugzScout pain as we’ve scaled up. Pain can lead to cases:

We generally agreed with these suggestions, and we’ve definitely known the frustration of some small process misbehaving and sending literally thousands of BugzScout reports our way.

Better.

The first thing we came up with was what we all thought would be a completely amazing BugzScout-esque product which could solve the BugzScout use case perfectly. But we didn’t build that… its scope was slightly larger than the part-of-a-week we wanted to spend on it. Plus, building a new product wouldn’t have solved our immediate problems fast enough. Our driving force behind the improvements became the following insight:

Sometimes you get a human-readable number of BugzScout reports. In these cases, you absolutely want the full error text from each occurrence, and it’s reasonable to route the event through all of the standard notification hooks. If someone doesn’t want to hear more about this error, they can direct BugzScout to stop reporting via editing the case.

Other times, you get so many reports that no human will read them. The case is spammed with stack traces and error notifications. After some point, additional stack traces are of no use — you’re not going to read through them anyway, they just make the case cumbersome. At this scale, you need BugzScout to do a few things:

  1. Shut up and let me fix it. You’ve already gotten a bunch of emails about the problem- one additional email per occurrence is of no use to anyone, but can legitimately hinder your efforts to actually deal with the problem.
  2. Help me know I’ve fixed it. It’s always been possible to determine if more reports are coming in by either watching the occurrence count of the BugzScout case or by monitoring when the case was last modified by BugzScout. Unfortunately, if you wanted to accomplish #1 by setting BugzScout to ‘Stop Reporting’, you’d also stop getting updated timestamps from when new reports came in.

We decided that reconciling #1 and #2 would be a great improvement for BugzScout and would be well within the scope of a few days of development. We felt confident that this type of change would solve our pain point, but before we went any further we wanted to make sure we weren’t operating in a no-fact zone. We reached out to our SaaS platform and gathered some anonymous data on how people were using BugzScout. The data confirmed our guess: Our use cases are valid and a significant amount of people are using BugzScout-based error reporting.

We settled on:

  • BugzScout will now automatically place itself into “Stop Reporting” mode after 50 occurrences of a report.
  • Last Occurrence is a new case field which is stored alongside all BugzScout cases and is fully searchable, filterable, etc. Last Occurrence is the timestamp of the most recent BugzScout report, regardless of whether that report was recorded as a case event.

Resulting in:

  • Human-readable amounts of BugzScout reports should be unaffected.
  • Human-unreadable amounts BugzScout reports will automatically cut off after 50. This means that the bloody tide of email will be curbed; BugzScout cases are limited to having a workable number of events in them.
  • If it comes time to collect more reports, you can do this by editing the case and instructing Scout to ‘Continue Reporting’.
  • Last Occurrence is a new and useful filterable value.

Shipped.

We’ve been dogfooding the new BugzScout in our FogBugz environment for the last month and have been quite happy with the improvements. We’ve found that the automatic shutoff of case event generation after 50 reports has allowed us to function much better when dealing with issues at scale.

Here’s an example of how our team likes to monitor the incoming BugzScout reports using the new Last Occurrence column:

This isn’t the only way we triage our BugzScout reports, but this simple filter lets us quickly spot any issues that are happening right now and know if they’ve happened with enough frequency to warrant immediate attention.

These changes went live to FogBugz On Demand two days ago, so we hope that you’ve found them useful. Licensed FogBugz customers will get these changes in our next licensed release.

Let Them Have Cake … And Ice Cream Too!

November 17th, 2011 by Rock Hymas

Consider a cake shop owner in a small town in Siberia. He sells the best cake around. Whenever someone wants a treat after dinner they stroll down to the cake shop and get a nice big slice of cake. But along comes a new treat: ice cream. Our cake shop owner ridicules his neighbor for starting an ice cream stand, saying no one will buy it because it’s cold. This is Siberia, after all. But rather than running an oven all the time, she can just keep her ice cream outside in the freezing cold, so it sells for less. Suddenly a whole bunch of people who could never afford cake are stopping at the ice cream stand after both lunch and dinner. It’s cheap, it tastes good, and the teenagers are having contests to see how much they can eat before passing out from brain freeze. It seems the whole town is there, and some of the cake shop customers start getting ice cream just because they want to hang out with their friends at the ice cream stand. All of a sudden the neighbor is rolling in the dough and she wants to buy out the cake shop since they have a great location.

Now suppose the owner of the cake shop recognizes that lots of his customers will like the ice cream (even in Siberia) because it’s so much cheaper. So he sets up an ice cream stand and hires his neighbor to start selling it as fast as possible. He notices that some of his regular cake shop customers are going to the ice cream stand instead, because it’s cheaper. So cake sales are down a little. Rather than shutting down the ice cream stand though, he brings it into the cake shop, adds a special “cake” flavored ice cream, and becomes the town hero. Not only has he saved his business, but he’s also been able to meet the dessert needs of more of his fellow townspeople. Cake is selling even better than before, ice cream is selling even better than that, and the cake-fanatics and ice cream groupies all get to hang out together.

Clayton Christensen’s talk at this year’s Business of Software was all about how companies disrupt, and are disrupted by, other companies. In building a product, you (or those who came before you) made decisions that are really hard to change after the fact. That’s fine; those “stakes in the ground” are what made the product successful. But it also limits the viable lifetime of the product. At some point disruption happens.

Disruption =

Larger Market + Lower Price + Different Measure

 

Professor Christensen pointed out that disruption occurs when a company solves a given problem for a larger audience at a lower price point with a different measuring stick for comparing value. Companies that successfully avoid being disrupted are usually able to do so only by disrupting themselves. Few companies are able to pull that trick off, and it typically involves having a different team or business unit set up in order to avoid all the baggage that the last-generation products carry with them.

What does this have to do with Fog Creek? Well, I’ll admit that I was a little skeptical when Fog Creek launched Trello. My worries pretty much lined up with those outlined in this post from a FogBugz customer. Though it’s taken some time, I’m starting to see how important it is for Fog Creek to prepare for the disruption of its flagship product, FogBugz.  By doing so, we can make sure FogBugz will keep solving our customers problems and keep making us money.

Trello fits the model for disrupting Fogbugz. It solves the problem of planning the work on a project for a larger audience than just software companies, at a lower price point than a FogBugz or a Jira, with a different measuring stick: putting Trello and FogBugz next to each other on a feature comparison chart doesn’t make any sense.

Trello’s target market is much larger than that of FogBugz. Where FogBugz targeted software development teams with features like bug tracking, automated crash reporting, and evidence-based scheduling, Trello can provide value to any group of two or more people working together on something that can be broken down into steps. Even though any group of people could use FogBugz to do the same thing, using FogBugz doesn’t really make sense when you’re in HR doing hiring, or in law working through cases, or in a studio vetting country bands. Using Trello does.

Additionally, Trello has a lower price point: free. Everything currently offered by Trello is free, and will remain so going forward. Yes, there will probably be value-added features and services that Fog Creek will charge for at some point. Compared to free, though, FogBugz is expensive at $25 per user per month. When you just want something simple to plan your wedding, that doesn’t make any sense. But if you’re managing software projects for reasonably complex products, then FogBugz easily adds that much value, and our customers make that clear by coming back again and again.

Trello also has a different measuring stick. And that’s the real reason it will eventually overtake FogBugz, even for software projects. Or rather, it will take over some of the roles that FogBugz fills in a software development company. We already use it here at Fog Creek to manage our work at a coarse-grained level. It provides a potentially public view into product development, which is cool to see.

The real key, though, is that Trello, like FogBugz, is opinionated–but it has very different opinions. Rather than seeing work on a project as a large set of small items that need to be tracked individually, it sees project work as a small set of somewhat larger tasks that fit into a bigger whole, a workflow defined by the team. If FogBugz tried to create some kind of dashboard view of your bugs to compete with Trello, you’d be so overwhelmed by minutia that you’d give up and walk away. No one wants that kind of view when they’re dealing with hundreds or thousands of individuals cases. But Trello redefines the way we see our project work and that fundamentally changes the game.

Wait a sec! I’m on the FogBugz team. What am I saying?! Am I just making a Steve Yegge “TMI” mistake by posting this publicly? Am I talking myself out of a job?

 

TMI?

 

I don’t think so. And here’s why.

The same legacy that prevents it from winning in the larger Trello market gives it a competitive advantage in the market for software development teams. FogBugz will continue to make money, and it is still growing at a nice pace. It needs investment, but not the kind of investment that would attempt to turn it into Trello. Rather, the kind of investment that will take advantage of disrupting products like Trello while preserving it’s usefulness in the niche of software development teams.

And our customers, for the most part, aren’t going to jump ship for Trello anytime soon. Currently, Trello can replace only a very small part of what FogBugz provides. One customer pointed out that it cannot handle bulk editing, screenshot captures are painful, and categorization and search aren’t designed for the situation where you have lots of items. Additionally, FogBugz supports incoming and outgoing email, automated crash reports, and deep hierarchies of work. You can install it within your network and use it completely internally. It’s also got awesome source control integration with Kiln. These are all things that software development teams care about, often passionately. Trello, and other products like it, may eventually meet some of these needs, or integrate with other tools that do, but that will take time. Time that will allow FogBugz to further differentiate itself.

Besides, learning new ways of working is hard. Anecdote time! We spent some time over the last few months rethinking the UI for FogBugz. As the team lead, I made the call to focus on that, and did what I could to protect the team through the process. Unfortunately, when it was done, Joel pointed out that it wouldn’t fly with our customers. Why? Because we “moved the cheese” in too many ways. It would have required our customers to learn new ways of working, and human nature doesn’t like to do that. Though that does limit what we can do with FogBugz going forward, it also strengthens the ties that our current customers have with the product. They know where to click, which keyboard shortcuts to use, and they know what to expect. That helps them work faster, get in the flow, and keep the boss happy.

Finally, and related to the last point, FogBugz has an ecosystem of supporting technology around it. When our customers start using FogBugz and Kiln, they often integrate with a set of tools and technology. This is one reason it’s harder to innovate on those products, because our customers don’t just rely on not having to learn new ways of working, they also rely on their custom plugins not breaking, on their random Python scripts still working, and on third-party tools continuing to integrate well with FogBugz. Each of those is a barrier to entry – they make it harder for a competing product to win our customers away from us (yep, even if the competitor is made by us as well) because they also add value for the customer.

In short, for almost all of FogBugz existing customers, and most of the larger market of customers using a competing bug tracker, using Trello instead is not the right business decision. And within that market FogBugz can make sure that business decision doesn’t change by doing the right kinds of investment. Investment that will keep FogBugz relevant and growing into the future is core-competency investment, not more features or chasing faster competitors in a race decided by a radically different “finish line”.

And there are tons of things we can do in the core of FogBugz: reduce the complexity of the product both for our users and for our developers; make it faster; phase out old features that aren’t being used by anyone; fix the backlog of bugs; improve our up-time; integrate with Trello and other apps. That last point is probably the most salient. As Trello grows and becomes a better fit for certain kinds of project management work, FogBugz can increasingly integrate with and offload those areas to Trello. At the same time, it can target specific problems that software development teams face, and provide value by solving them well.

In the end our customers will be able to have their cake … and their ice cream too.

FogBugz and Kiln Build and Release Report Card

November 3rd, 2011 by Rock Hymas

My wife and I are a couple months into our first year of homeschooling, and we’ve been discussing how the kids are doing with it, and the challenges we’ve faced as their teachers and parents. Those discussions have led us to make some important changes, in the same way that a school report card can get parents and children to make changes that lead to more learning and happier kids. In that spirit, I offer here a report card on the build and release management work we’ve been doing on FogBugz and Kiln [1] over the last 12-18 months.

About a year ago, I was in the middle of writing a series of posts about the practices of build and release management. Many of those practices came from looking at what we were doing with FogBugz and Kiln and identifying what worked, and what didn’t. Others came from what I saw and experienced while working within the Microsoft Office organization, and still more came from discussions within our team at the Creek. Though in some areas we were doing things right, most of the posts were a description of what our existing build and release (non-)system was doing utterly wrong and what I hoped we could change to fix it. So the series was often written in a spirit of hope that we would one day live up to the ideal.

In fact, you could take many of the posts I wrote last fall and read them as the opposite of how things existed at Fog Creek in the summer of 2010. So, in the spirit of Jason Cohen’s recent BoS talk about honesty, I’m going to be brutally honest about how we were doing and how we are now doing.

First, how we were doing. Here’s the report card for June of 2010, divided into subjects, of course.

Report Card for June 2010
Subject Grade
Fast builds/deploys

Deploying upgrades to www.fogcreek.com takes over an hour

Other builds and deployments often take much longer than they need to

Upgrades to FogBugz or Kiln often involve downtime of a few seconds to half an hour or more

D
No hard dependencies

Checked out source code is tied to absolute paths in some cases

The build and deployment scripts are full of hard coded paths and other hard dependencies

F
Single commands (automate, automate, automate)

We can’t run most builds with a single command

Many of the build and deployment scripts are combined

Deploying a new version takes multiple steps

Different scripts are used for dev builds vs official builds

Different configurations of the build use different build scripts

There is no tooling to make it easy to setup your dev system

There are no scripts to configure a new server for our hosted environment, or a new dev box for development

D
Staging Environment

We have no staging environment for our hosted FogBugz and Kiln products

F
Continuous Integration

There is no continuous integration builds or tests running

F
Scripts @ production quality

The scripts are old, unmaintained, with lots of cruft

Many built binaries are stored directly in the VCS

D
Onboarding new developers

There is no easy way for devs to build installers

There are no build scripts that do incremental builds

D
Insight into builds and releases

Old builds are not saved for most official configurations

We aren’t tracking build statistics like failures, build quality, etc.

Logs of builds are not systematically kept and stored anywhere

Build failures do not automatically notify anyone, nor do successful builds

There are three different types of version numbers for our three different deployment targets

F

All in all, things were a mess. ”Good grief!”, I hear you cry. “So what have you done about these issues? Anything? What are you planning to do?” I’m glad you asked.

My initial goal in the role of build and release manager was to eliminate the position. I wanted to get things running smoothly, and spread the knowledge and ownership of the problems through the team, so that I could go back to doing product development. As such, a decent amount of the progress described here was done by other great developers here at the Creek. Back in January (when I joined FogBugz as the team lead), I thought I’d gotten about halfway through the work required for that to happen. But, of course, new ideas come up constantly, so maybe it never ends.

Since January, I haven’t been able to do as much. In addition to my small efforts, other great Creekers have picked up some of the slack. Here’s our report card for October 2011.

Report card for October 2011
Subject Grade
Fast builds/deploys

A new, fast build machine

Reduced web site deployments from taking ~80 minutes to taking ~8 minutes

FogBugz and Kiln deployments now faster, because they don’t also rebuild the product

Upgrades to FogBugz or Kiln still involve downtime of a few seconds to half an hour or more

C+
No hard dependencies

Removed all the absolute paths

Removed many other hard dependencies

Removed some remaining hard dependencies that occasionally caused build failures

B
Single commands (automate, automate, automate)

Mortar, an internal website for kicking off builds and deployments

Lots of help on this one from Benjamin at bitquabit

Separated build and deploy scripts for hosted builds

Some of the build and deployment scripts are still combined

Deploying a new version takes multiple steps

Different scripts are still used for dev builds vs official builds

Different configurations of the build still use different build scripts, but some combining work has been done

There is still no tooling to make it easy to setup your dev system

There are still no scripts to configure a new server for our hosted environment, or a new dev box for development

C+
Staging Environment

Still no progress on the staging environment

F
Continuous Integration

Continuous integration builds exist, mostly just building the products

Basic tests have been added to some continuous integration builds

B
Scripts @ production quality

Removed many checked in binaries, building them instead

Many scripts converted from FinalBuilder to Python, but a few still remain

B-
Onboarding new developers

Branch builds, for any branch a dev wants to setup

bf, a better tool for building FogBugz incrementally on dev machines

Aaron kick-started this and continues to be the driving force

There is still no easy way for devs to build installers

D
Insight into builds and releases

Saving old hosted builds

Moved to a single type of version number no matter the config

Build logs for all official builds

Cases filed on build failure

Notifying build owners when builds complete, successfully or not

We aren’t tracking build statistics like failures, build quality, etc.

B-

As you can see, there is still plenty of work to do. The glaring failure in both report cards is our lack of a staging environment. We’re now working on making that a reality, with high hopes that it will help us start catching a new class of bugs before they make it into our customers hands. As part of that work, we’ll also be able to work on:

  • Scripts for configuring our servers, by type
  • No-downtime upgrades
  • Move our internal dogfooding to the staging environment, for better consolidation and testing of deployment scripts

Other possibilities for further work should be pretty clear from the report card, but the staging environment is the key focus when it comes to improving our builds and releases.

One note about the culture for both FogBugz and Kiln. We’ve learned a ton in the last couple years by seeing at close range what can be done in greenfield development on products like Trello, or teams that actively maintain and improve their processes for builds and releases, like StackOverflow. Obviously, when working with a legacy product like FogBugz, the costs of implementing certain practices may vary a lot, and we have to take that into consideration, but the inspiration that comes from seeing what is possible keeps us working to make things better.

When I look at this report card, I feel like my oldest son a little bit. He’s our perfectionist, always expecting to get everything right the first time through, and pretty disappointed when that doesn’t happen. We’re hoping that some of the changes we make in our homeschooling will help him relax a bit so he can learn more freely. And yes, it’s somewhat humbling to look at our build and release report card and admit how far we have to go. But I have high hopes that in another six months we’ll have improved our grades again.

 

[1] What about Trello?

Trello has the awesome advantage of being greenfield development. As such, they’ve really started from the ground up by doing the right things when it comes to builds and releases. They frequently release midday with no downtime, they have a nice staging environment, their releases take almost no time at all. They have run into some interesting load challenges with updating their clients after an upgrade, but I’ll let the Trello team talk about that in their own sweet time.

Faces with Your Cases: Profile Pictures in FogBugz

August 2nd, 2011 by Steven Banks

Picture this.  You’re a FogBugz user and you were just assigned a case by Joe Shmoe from the other side of the floor.  You’ve heard his name a couple of times, and could probably pick him out if you had six guesses.  Anyway, after reading through the case,  you realize you know neither (a) why this case was assigned to you, nor (b) what at all you’re being asked to do.

At this point you have a few options.  Normally we would suggest that you assign the case back to Joe, asking for more clarification.  Or you could edit the case with your cry for help and notify Joe.

But this case has been set to FIX-ME-NOW-OR-WE-ALL-EXPLODE priority, and bouncing cases back and forth can take a while.  Why don’t we just find Joe and have a short chat with him?

But recall: you don’t know who Joe is!  Maybe your company has a directory.  And maybe it’s even up-to-date!  If so, that’s great!  Use it!  Find Joe!  But maybe there’s no directory.  And walking around looking for someone that you maybe should already know anyway doesn’t sound thrilling.

We Creekers aren’t too keen on awkward social embarrassment.  To spare you some, or maybe just to give you a chance to show off your favorite lolcats, we’re happy to introduce enhanced profile info in FogBugz!

We’ve been really busy working on the newest version of FogBugz and some of its features are getting an early release as we get them done.  This is one of them.

If you mouse over Joe’s name you can see his info — including a profile picture —  and you realize you would have picked him fourth if you had just guessed.

popup

You can upload a picture, or use Gravatar, or use the super-cute default-kiwi.  Licensed customers just need to upgrade to FogBugz version 8.5.122.  The feature is already live in FogBugz On Demand.

Default-Kiwi

By default, your Gravatar is used (or the kiwi, if you don’t have one).  If you don’t like the kiwi, or your Gravatar isn’t — ahem — work-appropriate, or you just have that picture you’ve been dying to show off that you uploaded as your Facebook profile picture but then everyone moved to Google+ and didn’t invite you so now you’re bitter and don’t want to join anyway, you should totally check out your User Options page, by clicking on My Settings (in the top right) –> Options.  There you’ll find your current picture, with options to upload a new one, use the kiwi, or use Gravatar.   After you make a choice, you get a sneak peek before having to commit.  Maybe that picture doesn’t look so great after all…

My Settings --> OptionsUser Options for Joe Shmoe

We’re also excited to announce that profile pictures have already jumped into Kiln.  If you’ve ever tried to follow a code review in which lots of people commented, you might remember how hard it is to tell who said what.  Those days are behind us!  Profile pictures in code reviews make such complicated reviews much easier to follow.  Even if you don’t recognize the pictures, you can see immediately how many commenters there are and which ones said what.

Code Review

And while Kiln code reviews are the first area to be graced with your attractive face, my bet is that they won’t be the last.  There’s a simple API in place for developers of FogBugz, Kiln, or any of their plugins to inject profile pictures wherever they see fit.   Just use the function GetProfilePictureUrl(pxSize) on the CPerson class, where pxSize is the sidelength in pixels of the square image you want (available as of API version 3.46 and FB version 8.5.122).  Then use that url as an image src and you’re all set.  And while profile pictures might seem a little gimmicky, they have the potential to add a touch of personality to an otherwise let’s-get-down-to-business product, while also greatly improving clarity and usability in places like code reviews or — imagine! — case histories.

 

Joe Shmoe’s profile picture is a CC image courtesy of Rodrigo Sá, and is originally entitled Série Nerd.

Project Groups – Reviving a Lost “Feature”

June 21st, 2011 by Adam Wishneusky

For FogBugz 8.0, we completely revamped the way permissions work to make them match what users are used to seeing in other applications and in operating systems.

People don’t think of adding projects to groups; they think of adding users to groups. It turns out, however, that adding projects to groups was something people found useful. (The evidence points to them finding it more useful than the permissions feature itself.) You could add all your projects your consulting client, Kitten Industries, Inc. to a group, then filter by that group and see all the cases in those projects. The group didn’t even have to have people in it!

To solve this problem, we enlisted the help of the FogBugz ecosystem. Super-user John Fuex used the FogBugz plugin architecture to implement Project Groups to revive the ability to collect various projects together as one could back in FogBugz 7.

Project Groups are easy to configure as an administrator from the Plugin page. Groups may contain many projects and projects may belong to many groups.

Project Group List

Specify a Project Group to show when editing a filter or search for a group with the projectgroup: search axis.

Searching for Project Groups in FogBugz

Project Groups is downloadable from the Plugin Gallery for FogBugz For-Your-Server, or if you use FogBugz On Demand, it is installed by default (available tomorrow).