The document presents a detailed overview of Bonfire, an exploratory testing tool integrated with Jira, including its functionalities, challenges, and techniques for supporting multiple Jira versions. It discusses issues such as Java API changes, testing strategies, and the importance of continuous integration, while providing insights into effective plugin development practices. Additionally, it covers remote Jira integration and best practices for handling metadata and issue creation.

1. Saturday, 1 October 2011

2. Bonfire
Howʼd you do that?
Ian Grunert
Developer, Atlassian
2
Saturday, 1 October 2011

3. Agenda
3
Saturday, 1 October 2011

4. Agenda
• What is Bonfire?
3
Saturday, 1 October 2011

5. Agenda
• What is Bonfire?
• Building plugins for
multiple JIRA
versions
3
Saturday, 1 October 2011

6. Agenda
• What is Bonfire?
• Building plugins for
multiple JIRA
versions
• JIRA integration in
Bonfire - problems
and solutions
3
Saturday, 1 October 2011

7. What is Bonfire?
4
Saturday, 1 October 2011

8. What is Bonfire?
• Exploratory
testing tool
4
Saturday, 1 October 2011

9. What is Bonfire?
• Exploratory
testing tool
• JIRA plugin
targeting multiple
JIRA versions
4
Saturday, 1 October 2011

10. What is Bonfire?
• Exploratory
testing tool
• JIRA plugin
targeting multiple
JIRA versions
• Browser
extension for
major browsers
4
Saturday, 1 October 2011

11. Bonfire -> JIRA Integration
• Browser extension -
JIRA client
• Submit bug reports
directly from your
browser
5
Saturday, 1 October 2011

12. Bonfire -> JIRA Integration
• JIRA Plugin - track and
manage testing activities
• Test Sessions
• Session Notes
• http://
www.atlassian.com/
bonfire
6
Saturday, 1 October 2011

13. Building multiple JIRA version
supported plugins"
7
Saturday, 1 October 2011

14. Building multiple JIRA version
supported plugins"
• Why?
7
Saturday, 1 October 2011

15. Building multiple JIRA version
supported plugins"
• Why?
• Problem points?
7
Saturday, 1 October 2011

16. Building multiple JIRA version
supported plugins"
• Why?
• Problem points?
• Some Solutions.
7
Saturday, 1 October 2011

17. Maximise your customer base
• Increase the size
of your market
• Should try and
support two
versions back.
Earlier 4.0 4.1 4.2 4.3
8
Saturday, 1 October 2011

18. Multiple JIRA instances
• Deploy to multiple internal
instances
• For example,
https://support.atlassian.com/
is 4.3, where as
https://jira.atlassian.com/ is
4.4.
9
Saturday, 1 October 2011

19. Be ready for upgrades
• Test against EAPs!
• Give feedback.
• Participate in API building
• Support JIRA 5.0 from
launch
10
Saturday, 1 October 2011

20. Problems
11
Saturday, 1 October 2011

21. Problems
• Java API changes
11
Saturday, 1 October 2011

22. Problems
• Java API changes
• JS and Markup changes
11
Saturday, 1 October 2011

23. Problems
• Java API changes
• JS and Markup changes
• Testing across multiple
versions
11
Saturday, 1 October 2011

24. Branching
12
Saturday, 1 October 2011

25. Branching
• Cleaner code
12
Saturday, 1 October 2011

26. Branching
• Cleaner code
• Is this good or bad?
12
Saturday, 1 October 2011

27. Branching
• Cleaner code
• Is this good or bad?
• Overhead
12
Saturday, 1 October 2011

28. Branching
• Cleaner code
• Is this good or bad?
• Overhead
• Builds
12
Saturday, 1 October 2011

29. Branching
• Cleaner code
• Is this good or bad?
• Overhead
• Builds
• Merging
12
Saturday, 1 October 2011

30. Branching
• Cleaner code
• Is this good or bad?
• Overhead
• Builds
• Merging
• Testing
12
Saturday, 1 October 2011

31. One build, multiple versions
13
Saturday, 1 October 2011

32. One build, multiple versions
• Messier code
13
Saturday, 1 October 2011

33. One build, multiple versions
• Messier code
• No merging
13
Saturday, 1 October 2011

34. One build, multiple versions
• Messier code
• No merging
• Shipping one jar
13
Saturday, 1 October 2011

35. One build, multiple versions
• Messier code
• No merging
• Shipping one jar
• All tests in one branch
13
Saturday, 1 October 2011

36. One build, multiple versions
• Messier code
• No merging
• Shipping one jar
• All tests in one branch
• Know when touching
problem areas
13
Saturday, 1 October 2011

37. Six multi-version plugin
techniques
14
Saturday, 1 October 2011

38. Six multi-version plugin
techniques
1. CI using AMPS
14
Saturday, 1 October 2011

39. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
14
Saturday, 1 October 2011

40. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
3. Non-compile breaking API changes - BuildUtilsInfo
14
Saturday, 1 October 2011

41. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
3. Non-compile breaking API changes - BuildUtilsInfo
4. UI location changes - Web fragment conditions
14
Saturday, 1 October 2011

42. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
3. Non-compile breaking API changes - BuildUtilsInfo
4. UI location changes - Web fragment conditions
5. Compile breaking changes - Reflection
14
Saturday, 1 October 2011

43. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
3. Non-compile breaking API changes - BuildUtilsInfo
4. UI location changes - Web fragment conditions
5. Compile breaking changes - Reflection
6. Compile breaking changes - Dynamic module types
14
Saturday, 1 October 2011

44. Continuous Integration
• Run CI against all supported versions
• Use testGroups in AMPS to facilitate this
• Quickly identify compile-time issues introduced
15
Saturday, 1 October 2011

45. 16
Saturday, 1 October 2011

46. 17
Saturday, 1 October 2011

47. JavaScript / Markup changes
• AJS.version to find AUIʼs version, split the code path
• https://developer.atlassian.com/display/AUI/AUI
+Version+Matrix
18
Saturday, 1 October 2011

48. 19
Saturday, 1 October 2011

49. 20
Saturday, 1 October 2011

50. Querying JIRA version
• BuildUtilsInfo in JIRA can be used to find the JIRA
version and split the code path
21
Saturday, 1 October 2011

51. Web-fragment Conditions
• Allows you to define a boolean condition as to whether
or not a web-fragment shows up
• IsPriorToJIRAVersion condition to only show web
fragments in certain JIRA versions (uses
BuildUtilsInfo)
22
Saturday, 1 October 2011

52. Example
23
Saturday, 1 October 2011

53. Compile breaking changes -
Reflection"
• Use this:
• To load a class only present in later versions of JIRA
• To load a class that changes names across JIRA
versions
24
Saturday, 1 October 2011

54. Example
25
Saturday, 1 October 2011

55. Example
26
Saturday, 1 October 2011

56. How does this look in JIRA 5?
• JIRA 5.0 removes OSUser
entirely
• Replaced with Crowd user
• Large scale compile time
breaking changes
27
Saturday, 1 October 2011

57. We tried branching
• Approach taken by Bonfire was to drop 4.2 support,
and remove as much OSUser as possible
• Some instances of OSUser couldnʼt be removed
(IssueTabPanel for example)
• Then create a branch, and change the imports for the
branch
28
Saturday, 1 October 2011

58. Deprecation pains
• In JIRA 4.3 / 4.4, use special methods to get crowd
user object
• jiraAuthContext.getUser for OSUser
• jiraAuthContext.getLoggedInUser() for Crowd User
• OSUser based methods are deprecated in 4.3 / 4.4
29
Saturday, 1 October 2011

59. Deprecation pains
• In JIRA 5.0, the better 4.3/4.4
Crowd user methods are now
deprecated (moved to nicer
named methods)
• Doing the right thing yields
lots of warnings
30
Saturday, 1 October 2011

60. Branching sucks!
• For the same reasons outlined before
• No eyes on JIRA 5.0 changes
• Merge pain
• Multiple jars
• How can we fix this?
31
Saturday, 1 October 2011

61. Dynamic module types
• Don Brown created jira4-compat to allow Speakeasy
to support 4.2 -> 5.0 without branching
• Uses dynamic plugin module types to allow for new,
cross version compatible module types
• 4 maven modules, compile different maven modules
based on JIRA version
• FactoryBean Spring Component to inject the correct
dependency 32
Saturday, 1 October 2011

62. Bonfire multi-version
experiences - takeaways
1. Multi-version support - you should be doing it!
2. Donʼt have to branch to do multi-version.
3. The documentation can help!
http://confluence.atlassian.com/display/JIRA/Plugin
+Developer+Notes+for+JIRA+5.0
33
Saturday, 1 October 2011

63. Bonfire remote JIRA integration
34
Saturday, 1 October 2011

64. Bonfire remote JIRA integration
35
Saturday, 1 October 2011

65. Bonfire remote JIRA integration
1. Authentication
35
Saturday, 1 October 2011

66. Bonfire remote JIRA integration
1. Authentication
2. Issue metadata
35
Saturday, 1 October 2011

67. Bonfire remote JIRA integration
1. Authentication
2. Issue metadata
3. Issue Creation
35
Saturday, 1 October 2011

68. Authentication
• Canʼt store the password
• Ideally, single step
authentication
36
Saturday, 1 October 2011

69. Authentication
• Use JIRA REST
• Returns a cookie
• Use cookie for all future
requests
• Re-authenticate on
cookie timeout
37
Saturday, 1 October 2011

70. Issue metadata
• Need metadata to draw the
issue creation form
• XML-RPC
• Missing fields
• Could not create on some
instances
38
Saturday, 1 October 2011

71. Issue metadata
• Now on custom REST
• Bad: extra code
• Good: In control, works on
all instances, can add new
Bonfire specific features
39
Saturday, 1 October 2011

72. Issue creation
• XML-RPC
• Gaps filled with REST
(e.g. labels)
• SOAP for attachments
40
Saturday, 1 October 2011

73. Issue creation
• Now on custom REST
• Bad: extra code
• Good: In control, works on
all instances, can add new
Bonfire specific features
• Déjà vu?
41
Saturday, 1 October 2011

74. Good news, everyone!
• In JIRA 5.0, neither custom
REST resource would be
required
42
Saturday, 1 October 2011

75. Bonfire Remote API
experiences - takeaways
1. Test on real / complex data!
(use atlas-create-home-zip)
2. Favour REST
3. Donʼt fear custom REST resources
43
Saturday, 1 October 2011

76. Thank you!
Saturday, 1 October 2011