Bonfire... How'd You Do That?! - AtlasCamp 2011

1,536 views
1,414 views

Published on

How do you write a JIRA plugin that works across 4.2, 4.3 and 4.4? How can you find the metadata for the JIRA issue creation form? How can you create the issue itself, and attach the screenshot? And how is this going to change in JIRA 5.0 and beyond? This talk will cover all this, and more!

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,536
On SlideShare
0
From Embeds
0
Number of Embeds
545
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Bonfire... How'd You Do That?! - AtlasCamp 2011

  1. 1. Saturday, 1 October 2011
  2. 2. Bonfire Howʼd you do that? Ian Grunert Developer, Atlassian 2Saturday, 1 October 2011
  3. 3. Agenda 3Saturday, 1 October 2011
  4. 4. Agenda • What is Bonfire? 3Saturday, 1 October 2011
  5. 5. Agenda • What is Bonfire? • Building plugins for multiple JIRA versions 3Saturday, 1 October 2011
  6. 6. Agenda • What is Bonfire? • Building plugins for multiple JIRA versions • JIRA integration in Bonfire - problems and solutions 3Saturday, 1 October 2011
  7. 7. What is Bonfire? 4Saturday, 1 October 2011
  8. 8. What is Bonfire? • Exploratory testing tool 4Saturday, 1 October 2011
  9. 9. What is Bonfire? • Exploratory testing tool • JIRA plugin targeting multiple JIRA versions 4Saturday, 1 October 2011
  10. 10. What is Bonfire? • Exploratory testing tool • JIRA plugin targeting multiple JIRA versions • Browser extension for major browsers 4Saturday, 1 October 2011
  11. 11. Bonfire -> JIRA Integration • Browser extension - JIRA client • Submit bug reports directly from your browser 5Saturday, 1 October 2011
  12. 12. Bonfire -> JIRA Integration • JIRA Plugin - track and manage testing activities • Test Sessions • Session Notes • http:// www.atlassian.com/ bonfire 6Saturday, 1 October 2011
  13. 13. Building multiple JIRA version supported plugins" 7Saturday, 1 October 2011
  14. 14. Building multiple JIRA version supported plugins" • Why? 7Saturday, 1 October 2011
  15. 15. Building multiple JIRA version supported plugins" • Why? • Problem points? 7Saturday, 1 October 2011
  16. 16. Building multiple JIRA version supported plugins" • Why? • Problem points? • Some Solutions. 7Saturday, 1 October 2011
  17. 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 8Saturday, 1 October 2011
  18. 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. 9Saturday, 1 October 2011
  19. 19. Be ready for upgrades • Test against EAPs! • Give feedback. • Participate in API building • Support JIRA 5.0 from launch 10Saturday, 1 October 2011
  20. 20. Problems 11Saturday, 1 October 2011
  21. 21. Problems • Java API changes 11Saturday, 1 October 2011
  22. 22. Problems • Java API changes • JS and Markup changes 11Saturday, 1 October 2011
  23. 23. Problems • Java API changes • JS and Markup changes • Testing across multiple versions 11Saturday, 1 October 2011
  24. 24. Branching 12Saturday, 1 October 2011
  25. 25. Branching • Cleaner code 12Saturday, 1 October 2011
  26. 26. Branching • Cleaner code • Is this good or bad? 12Saturday, 1 October 2011
  27. 27. Branching • Cleaner code • Is this good or bad? • Overhead 12Saturday, 1 October 2011
  28. 28. Branching • Cleaner code • Is this good or bad? • Overhead • Builds 12Saturday, 1 October 2011
  29. 29. Branching • Cleaner code • Is this good or bad? • Overhead • Builds • Merging 12Saturday, 1 October 2011
  30. 30. Branching • Cleaner code • Is this good or bad? • Overhead • Builds • Merging • Testing 12Saturday, 1 October 2011
  31. 31. One build, multiple versions 13Saturday, 1 October 2011
  32. 32. One build, multiple versions • Messier code 13Saturday, 1 October 2011
  33. 33. One build, multiple versions • Messier code • No merging 13Saturday, 1 October 2011
  34. 34. One build, multiple versions • Messier code • No merging • Shipping one jar 13Saturday, 1 October 2011
  35. 35. One build, multiple versions • Messier code • No merging • Shipping one jar • All tests in one branch 13Saturday, 1 October 2011
  36. 36. One build, multiple versions • Messier code • No merging • Shipping one jar • All tests in one branch • Know when touching problem areas 13Saturday, 1 October 2011
  37. 37. Six multi-version plugin techniques 14Saturday, 1 October 2011
  38. 38. Six multi-version plugin techniques 1. CI using AMPS 14Saturday, 1 October 2011
  39. 39. Six multi-version plugin techniques 1. CI using AMPS 2. Javascript / Markup changes - AJS.version 14Saturday, 1 October 2011
  40. 40. Six multi-version plugin techniques 1. CI using AMPS 2. Javascript / Markup changes - AJS.version 3. Non-compile breaking API changes - BuildUtilsInfo 14Saturday, 1 October 2011
  41. 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 14Saturday, 1 October 2011
  42. 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 14Saturday, 1 October 2011
  43. 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 14Saturday, 1 October 2011
  44. 44. Continuous Integration • Run CI against all supported versions • Use testGroups in AMPS to facilitate this • Quickly identify compile-time issues introduced 15Saturday, 1 October 2011
  45. 45. 16Saturday, 1 October 2011
  46. 46. 17Saturday, 1 October 2011
  47. 47. JavaScript / Markup changes • AJS.version to find AUIʼs version, split the code path • https://developer.atlassian.com/display/AUI/AUI +Version+Matrix 18Saturday, 1 October 2011
  48. 48. 19Saturday, 1 October 2011
  49. 49. 20Saturday, 1 October 2011
  50. 50. Querying JIRA version • BuildUtilsInfo in JIRA can be used to find the JIRA version and split the code path 21Saturday, 1 October 2011
  51. 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) 22Saturday, 1 October 2011
  52. 52. Example 23Saturday, 1 October 2011
  53. 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 24Saturday, 1 October 2011
  54. 54. Example 25Saturday, 1 October 2011
  55. 55. Example 26Saturday, 1 October 2011
  56. 56. How does this look in JIRA 5? • JIRA 5.0 removes OSUser entirely • Replaced with Crowd user • Large scale compile time breaking changes 27Saturday, 1 October 2011
  57. 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 28Saturday, 1 October 2011
  58. 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 29Saturday, 1 October 2011
  59. 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 30Saturday, 1 October 2011
  60. 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? 31Saturday, 1 October 2011
  61. 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 32Saturday, 1 October 2011
  62. 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 33Saturday, 1 October 2011
  63. 63. Bonfire remote JIRA integration 34Saturday, 1 October 2011
  64. 64. Bonfire remote JIRA integration 35Saturday, 1 October 2011
  65. 65. Bonfire remote JIRA integration 1. Authentication 35Saturday, 1 October 2011
  66. 66. Bonfire remote JIRA integration 1. Authentication 2. Issue metadata 35Saturday, 1 October 2011
  67. 67. Bonfire remote JIRA integration 1. Authentication 2. Issue metadata 3. Issue Creation 35Saturday, 1 October 2011
  68. 68. Authentication • Canʼt store the password • Ideally, single step authentication 36Saturday, 1 October 2011
  69. 69. Authentication • Use JIRA REST • Returns a cookie • Use cookie for all future requests • Re-authenticate on cookie timeout 37Saturday, 1 October 2011
  70. 70. Issue metadata • Need metadata to draw the issue creation form • XML-RPC • Missing fields • Could not create on some instances 38Saturday, 1 October 2011
  71. 71. Issue metadata • Now on custom REST • Bad: extra code • Good: In control, works on all instances, can add new Bonfire specific features 39Saturday, 1 October 2011
  72. 72. Issue creation • XML-RPC • Gaps filled with REST (e.g. labels) • SOAP for attachments 40Saturday, 1 October 2011
  73. 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? 41Saturday, 1 October 2011
  74. 74. Good news, everyone! • In JIRA 5.0, neither custom REST resource would be required 42Saturday, 1 October 2011
  75. 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 43Saturday, 1 October 2011
  76. 76. Thank you!Saturday, 1 October 2011

×