TargetProcess v.2.8 release took longer than expected. The reason as always is changing requirements When we planned release roadmap we thought Bugzilla integration going to be easy and release will be quick. But when development started, we decided to add Plugins Framework into TargetProcess.

Why? We have many requests about different features. If we will implement them all, it will kill the product. Moreover, it will take YEARS to implement at least half of them. Plugins give us flexibility. In many cases we will not say “No, we think this feature is not required to other customers and will not implement it“. Instead we may say “Ok, if you need it you have two options: implement it as a plugin or request customization service and we will create the plugin for you“. Sounds better, isn’t it? And it do resolve the unique problem that company has.

So far plugins allows you to operate with business logic only. There are no API for UI widgets you can create, but we will add them in future. Still plugins framework provides a real customization power:

• You may influence entities workflow and do literally any action you want.
• You may integrate with almost any external system (for example, now integration with another bug tracking tool will take about a week!).
• You may create specific reports and gather required data.

There are many possible applications, creativity is enormous thing when it is supported by flexibility.

That was a big addition and it took time to implement and polish. Still we don’t even expect it is complete neither “perfect”. We pretty sure that first real usages will show us the best road for improvements.

Bugzilla integration was implemented as the first real plugin. It synchronizes bugs in Bugzilla and TargetProcess, thus separating bug tracking and planning concerns (use right tool for right job). The plugin provided with full source code, so you may customize it as required.

Other significant improvement is better custom fields support (look, almost all new features are about flexibility!) Now custom fields may be defined for each process. One team may define Risk for user story, while another doesn’t. Now TargetProcess supports that. Custom fields were added into Custom Reports (they have similar names, it would be the crime to not integrate them). Also custom fields now visible in ToDo list and in Iteration plan (with filters).

As a final note, we fixed more than 50 issues in v.2.8. Most of them are small, but annoying (for example, semicolon separator in CSV export or filters remembering in Iteration Plan).

BTW, we have nice plans for v.2.8 like Visual Studio plugin and Test Track Pro integration. Enjoy the trip!

It will be possible to create custom plugins in the next release of TargetProcess. We’ve already created plugins architecture and are polishing some things at the moment. Plugins developers will be provided with С# API and some samples (Bugzilla Integration is a plugin itself for example and it will be released as an open source project).

As a plugin developer you will be able to:

• Subscribe to different events in TargetProcess and do some actions.
• Schedule plugin execution (for example, each 10 minutes)
• Create different settings for plugins for different projects and different processes

As we see, this opens huge customization abilities for TargetProcess. Some examples of useful plugins:

• Change Request state to Closed when correspondent Bug or User Story closed
• Create a report and email it to a team lead each Friday
• Post new bugs or update existing bugs to third-party bug tracking application that has web services API

We are going to build a community around plugins implementation for TargetProcess and support it with all answers, samples, implementation and development. Stay tuned!