Change and Release Management with JIRA and Bamboo Jonathan Doklovic, Systems Bliss Kevin Behrens, Internet Broadcasting

1. 1
1

2. Change and Release Management
with JIRA and Bamboo
Jonathan Doklovic, Founder, Sysbliss
Kevin Behrens, Release Manager, Internet Broadcasting
2
2

3. • Build and Integration Environment Consulting
• Plugins
• Bamboo JIRA Versions
• JIRA Workflow Designer
• Bamboo Pre/Post Commands
• Sysbliss AMF Server
• JIRA Fight!
3
3

4. Software Used
4
4

5. Dev Life cycle
5
5

6. Build & Release
• What works
• Edit, build and test locally on developers workstation
• Automated build in Bamboo after checkin
• Features and bugs tracked in JIRA
• Commits are linked to JIRA issues
• JIRA issues and commits are linked to builds
6
6

7. Build & Release
• Whatʼs missing
• Central management of build versions
• Releasing feature sets in JIRA
• Builds based on release level
• Parallel version development
• Bamboo plan simplification
7
7

8. JIRA Versions to the rescue
• Give Bamboo ability to intelligently retrieve current version from JIRA, injecting it
into the build
• Automatically release in JIRA upon successful build
• Release and snapshot builds can be tracked back to bamboo and SCM
• Automated tagging guided by version and release level
• Automatically branch to next version after release
8
8

9. Demo
• Build automation with JIRA Versions
9
9

10. Summary
• Added a version variable to maven POM
• Configured bamboo to build branches
• Used JIRA versions to specify which versions to build
• Used JIRA versions to build snapshots and releases
• Autobranch to next version
• Tag current version
• release version in JIRA
•
10
10

11. • Internet Broadcasting is the leading provider of local Web sites, content, and
advertising revenue solutions to the worldʼs largest and most successful media
companies.
• Over 70 websites deployed in a shared environment
• Publishing platform with 20 independently deployed components
11
11

12. Change Management
• Outages usually related to unexpected changes or problems in
software immediately after installation
• Communication is key
• Developers need to know of changes in other parts of the system
• Support needs to know about new features or changes
• Operations needs to know what to install
12
12

13. Change Management
• Why this is important
• Customers are fussy about uptime
• Why this was hard
• Over 100 deployable artifacts - war files and rpms
• Multiple levels of caching at CDN
• SLAs with customers define maintenance windows
13
13

14. Change Management
• What was working
• Automated builds
• Artifacts stored in central dependency manager repository
• Staging environment mirroring production
• Skilled Operations staff deploying software
14
14

15. Change Management
• What was missing
• Unified way to request deployment
• Sane way to triage requests
• No way to definitively link requests to a JIRA project/version
• Difficult to see status of request prior to deployment
• Difficult to see results after deployment
• Process was poorly understood
• Workflow was not programatically enforced
• Workflow to support release/rollback
15
15

16. JIRA Customizations to the rescue
• Request for Change project created with
• Custom issue types
• Highly customized screens based on issue type
• Custom field to link request with project being released
• plugin created to present a pulldown with projects and then versions in that project
• Multiple custom workflows
• Version Resolution custom report
16
16

17. Demo
• Change & Release Management with JIRA Versions
17
17

18. Custom workflow
18
18

19. Q&A
• What do you want to know?
19
19