SOASTA Webinar: Process Compression For Mobile App Dev 120612
•Download as PPT, PDF•
1 like•906 views
The webinar discusses continuous integration and automation for mobile development and testing. It presents tools from Atlassian, Zephyr, and SOASTA that can help automate the mobile development and testing process. Continuous integration with Bamboo can help developers integrate code changes more frequently and fail builds faster to catch bugs earlier. Zephyr provides test management to centralize test assets and provide visibility. SOASTA offers tools for test automation, real user monitoring, and performance/load testing to help achieve test completion with quality. Together these tools can help speed up the mobile development process through continuous integration, test automation, and visibility into the testing process.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to SOASTA Webinar: Process Compression For Mobile App Dev 120612
Similar to SOASTA Webinar: Process Compression For Mobile App Dev 120612 (20)
More from SOASTA
More from SOASTA (20)
Recently uploaded
Recently uploaded (20)
SOASTA Webinar: Process Compression For Mobile App Dev 120612
- 1. Presents Continuous Integration and Automation for Mobile Development & Test Webinar 1
- 2. Where to automate for rapid mobile dev and test TODAY’S PRESENTERS • Dave Meyer: Product Marketing Manager, Atlassian - @d_meyer • Sanjay Zalavadia: Director of Professional Services, Zephyr - @ZalinCal • Brad Johnson: VP Product & Channel Marketing, SOASTA - @bradjohnsonsv Leading Innovators in Software Development! - Helping teams build amazing software - Delivering real-time test management - The leader in mobile and cloud testing Aligned with a Common Goal High Speed Software Delivery 2
- 3. o Introduction o Poll Question o Continuous Integration and Bamboo for Mobile o Test Management and the CI process o Automation for continuous mobile testing Questions: - Please submit via Chat during event 3
- 4. o Shear Number of Devices (953M Smartphones) o Different Operating Systems o Scale of Global Customers (6B) o Dynamic Content (Video, Animation) o Rapid development driven by demand Manual Processes Can Not Keep Up 4
- 5. Pace and Scale of Mobile Fingers and Eyeballs VS. Development 5
- 6. SDLC tasks are a constant. Pace Isn’t 6
- 7. The Mobile Need is Elementary > More Progress in Less Time < 7
- 8. 8
- 9. We help plan, build, and launch great software Team Collaboration Track, Plan, Analyze ...and more! Track projects, events, & people Group Chat Agile project tracking Exploratory Testing • 23,000 customers in over 130 countries • Offices in Sydney, San Francisco & Amsterdam • A “leader” in ALM according to Gartner 9
- 10. Dave Meyer @d_meyer 10
- 11. Why does Continuous Integration matter? Find bugs faster Make merging suck less x 2 for Mobile Faster feedback loops Less lag time
- 12. If you’re going to fail, fail fast! #atlassian
- 13. Principles of CI o One (1) repo o Automate your builds! o Builds all the time! o Automate your tests! o Deploy, deliver, distribute, deploy, deliver ....
- 14. What does a CI tool do? UI Tests Clone repo Build Unit Tests Deploy to QA Integration Tests Deploy to Production API Tests Performance/Load Tests Smoke tests 14
- 15. Plan 15
- 16. Plan Stage Stage Stage 16
- 17. Plan Stage Stage Stage Job Job Job Job Job 17
- 18. Plan Stage Stage Stage Job Job Job Task Task Task Job Task Task Task Job Task Task Task 18
- 19. • Checkout from Source Control • SVN, Git, Hg, Perforce, CVS • Build Engine • Ant, Maven, MSBuilder, Rake, Grails, Ivy • Analysis & Reports • code coverage, static analysis, performance • Deployment • Tomcat, Heroku, Deploy It, LiveRebel, Artifactory, SCP, Script Tasks run sequentially inside their container: a Job 19
- 20. Plan Stage Stage Stage Job Job Job Task Task Task Job Task Task Task Job Task Task Task 20
- 21. Jobs • Group dependent Tasks together inside a Job to ensure order of execution • “Build & Package” Job = SCM Checkout Task + Checkstyle Task + Ant Task • Place independent Tasks in their own Jobs to tighten the feedback loop • “Integration Tests” Job = Maven Task • “UI Tests” Job = Maven Task • These two Jobs can run in any order, or simultaneousl Jobs run in parallel inside their container: a Stage 21
- 22. Plan Stage Stage Stage Job Job Job Task Task Task Job Task Task Task Job Task Task Task 22
- 23. Plans • Represents the complete set of actions taken with each build • Variety of triggers: • Change in SCM • Cron • Manual (push-button) • Parent Plans • Global elements you can fine-tune at the Plan level: • Variables • Repositories • Notifications • Permissions • Build Expiry 23
- 24. Up your Mobile Dev speed 1. Start failing faster 24
- 25. Up your Mobile Dev speed 1. Start failing faster 2. Don’t build alone 25
- 26. Up your Mobile Dev speed 1. Start failing faster 2. Don’t build alone 3. Atlassian <3 mobile devs 26
- 27. Up your Mobile Dev speed Blog: http://atlss.in/mobileCI 1. Start failing faster 2. Don’t build alone 3. Atlassian <3 mobile devs 27
- 28. Up your Mobile Dev speed Blog: http://atlss.in/mobileCI 1. Start failing faster 2. Don’t build alone 3. Atlassian <3 mobile devs 28
- 29. Up your Mobile Dev speed Blog: http://atlss.in/mobileCI 1. Start failing faster 2. Don’t build alone 3. Atlassian <3 mobile devs 29
- 30. Company overview profile o Founded in 2007 o 900+ global customers o Atlassian Integration Partner o Headquartered in Silicon Valley, CA CONTACT o Email: sales@getzephyr.com o Office: (510) 400-8656 o Home: getzephyr.com 30
- 31. Sanjay Zalavadia @ZalinCal 31
- 32. Challenges with Mobile App testing Transitional testing team •Seasonal testers •Globally distributed teams Huge testing footprint •Wide variety of platforms, devices, OS, languages, browser versions, MODS, carriers •Dealing with multiple marketplaces / ecosystems / product catalogs •Can’t write and manually execute separate tests Keeping track of what’s going on … •Hard to know where you are in your testing •Constant updates needed for the Business, Executives, PMs, etc .
- 33. Consequences if left unaddressed Lack of organized, re-useable systems: •Missed Deadlines •App certification process - rejection •Re-inventing the wheel Lack of Coverage •Quality issues •Low ratings, Poor reviews Lack of visibility •Lose track of where you are in your testing •QA = black hole
- 34. Get organized Centralize your test assets •Single test repository •Accessible and useable globally •Manual, automation and performance •3
- 35. Achieve test completion with Quality Automate •Build time verification •Utilize the cloud Performance testing •Not optional Maintain Consistency
- 36. Provide complete Visibility Accessibility to entire Project Team Metrics Availability 24 x 7 Real-time updates
- 37. Provide complete Visibility Accessibility to entire Project Team Metrics Availability 24 x 7 Real-time updates •5
- 38. Provide complete Visibility Accessibility to entire Project Team Metrics Availability 24 x 7 Real-time updates
- 39. Provide complete Visibility Accessibility to entire Project Team Metrics Availability 24 x 7 Real-time updates
- 40. o First End-to-End Mobile App Test Platform • First Cloud-Based Load Testing Solution • First Global Test Cloud (17 Countries, 100 Cities) • First Mobile Test Automation “Platform” • First real time RUM for web and mobile o Over 350 Global Corporate Customers • 10,000 Mobile Developers and Testers use CloudTest • Over 1,000 Mobile and Web Apps are Tested with CloudTest o Award Winning & Patented Technology • Named by Wall Street Journal Top 50 Hottest Companies three years running • Gartner Visionary Leader o Over 100+ Employees US, EMEA 40
- 41. Brad Johnson @bradjohnsonsv 41
- 42. Application Development Lifecycle Development & Build Functional Test Automation Application Real User Performance & Monitoring Load Testing 42
- 43. mov ile b Application Development Lifecycle Development & CI TouchTest Application mPulse CloudTest 43
- 44. 44
- 45. To Check in QA or Devs Users ☐ Test ✓ Pass Source Code Repository Results ☐ Fail Check out Run Tests Build Server Unit Tests 45
- 46. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on devices Push to devices In parallel Real Devices 46
- 47. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 47
- 48. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 48
- 49. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 49
- 50. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 50
- 51. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 51
- 52. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 52
- 53. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 53
- 54. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test Results ☐ Fail Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 54
- 55. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test Results ☐ Fail Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 55
- 56. To Check in or Devs Beta Users ☐ ✓ Pass Source Code Repository Test ☐ Fail Results Check out Bamboo Build Server Run Tests Bamboo Mac Agent Execute on Push to devices devices In parallel Real Devices 56
- 57. • No jailbreak required • No “rooting” required • No tethering required • No tethering required • iOS 5.0, 5.1, 6.0 • Android 2.3.3 • iPhone 3GS, 4, 4S, and 5 (Gingerbread) and later • iPad 1, 2, 3, 4 • Phones, tablets, and • iPad mini emulators • Simulators 57
- 58. • Download CloudTest Lite (http://www.soasta.com) • Includes TouchTest technology • Free for a single device • No expiration • Free support via CloudLink forums 58
- 59. It Doesn’t Matter Where You Start. JUST START! 59
- 60. Q&A RESOURCES www.SOASTA.com www.GetZephyr.com www.Atlassian.com Knowledge Center Products •White Papers •Zephyr Enterprise •Webinar Recordings •Zephyr Community •Case Studies •Zephyr for JIRA CloudLink Community Support Center •Support •Knowledge Base •Tutorials •ZephyrTV •Video •Community Forums Contact SOASTA: info@soasta.com 866.344.8766 Follow us: twitter.com/cloudtest facebook.com/cloudtest 60
Editor's Notes
- All of this is a really long way of saying that if your code is going to fail for any reason, we want to discover that failure as fast as possible so we can address it right away. (CLICK)
- So if we generalize that out, we get something this. The atomic unit in Bamboo is called a Plan. Plans are made up of one or more Stages; Stages are made up of one or more Jobs, and Jobs are made of up of one or more Tasks. Might seem like a lot of moving pieces, but they all have their purpose, which will become clear as we look at each of those elements in more depth. And look: build engineering is complicated. There ’ s just no getting around that. If it were easy, we wouldn ’ t need people to do the job that you guys are out there doing every day. Our job with Bamboo is to make your jobs suck less --hopefully a lot less.
- So if we generalize that out, we get something this. The atomic unit in Bamboo is called a Plan. Plans are made up of one or more Stages; Stages are made up of one or more Jobs, and Jobs are made of up of one or more Tasks. Might seem like a lot of moving pieces, but they all have their purpose, which will become clear as we look at each of those elements in more depth. And look: build engineering is complicated. There ’ s just no getting around that. If it were easy, we wouldn ’ t need people to do the job that you guys are out there doing every day. Our job with Bamboo is to make your jobs suck less --hopefully a lot less.
- So if we generalize that out, we get something this. The atomic unit in Bamboo is called a Plan. Plans are made up of one or more Stages; Stages are made up of one or more Jobs, and Jobs are made of up of one or more Tasks. Might seem like a lot of moving pieces, but they all have their purpose, which will become clear as we look at each of those elements in more depth. And look: build engineering is complicated. There ’ s just no getting around that. If it were easy, we wouldn ’ t need people to do the job that you guys are out there doing every day. Our job with Bamboo is to make your jobs suck less --hopefully a lot less.
- So if we generalize that out, we get something this. The atomic unit in Bamboo is called a Plan. Plans are made up of one or more Stages; Stages are made up of one or more Jobs, and Jobs are made of up of one or more Tasks. Might seem like a lot of moving pieces, but they all have their purpose, which will become clear as we look at each of those elements in more depth. And look: build engineering is complicated. There ’ s just no getting around that. If it were easy, we wouldn ’ t need people to do the job that you guys are out there doing every day. Our job with Bamboo is to make your jobs suck less --hopefully a lot less.
- So if we generalize that out, we get something this. The atomic unit in Bamboo is called a Plan. Plans are made up of one or more Stages; Stages are made up of one or more Jobs, and Jobs are made of up of one or more Tasks. Might seem like a lot of moving pieces, but they all have their purpose, which will become clear as we look at each of those elements in more depth. And look: build engineering is complicated. There ’ s just no getting around that. If it were easy, we wouldn ’ t need people to do the job that you guys are out there doing every day. Our job with Bamboo is to make your jobs suck less --hopefully a lot less.
- Grouping tasks into jobs is how you tell Bamboo what order your tasks must be run in. And because is possible to run two or more jobs simultaneously, jobs provide a way to organize your build into tasks that are dependent on each other, and tasks that are independent. For example, you may want to run Checkstyle on your code before building it --the idea being that if there are too many violations, we won ’ t even bother compiling. To accomplish this, there are actually 3 tasks involved, and they all have an upstream/downstream relationship. First, check out the code from source control; then run Checkstyle; then do the actual build. These tasks are grouped together in a job because they need to be executed in a certain order. Other places in your pipeline may include steps (ie, tasks) that are completely independent of each other and can be executed simultaneously or in no particular order. You may have one task that runs integration level tests, and another that runs UI tests. To save time, you would put those tasks into separate jobs, allowing them to be run in parallel so long as there are enough build agents available. (CLICK) So, agents and jobs are kind of tied to each other. And because of that, all tasks within a job are garunteed to be executed on the same agent. Therefore, it makes sense to perform certain peripheral functions at the Job level. Build requirements: because all the tasks in a job will be executed on the same build agent, it makes sense to define the build requirements in the aggregate, at the Job level. Artifacts: makes sense to grab artifacts at the point where the agent has completed its task list and is ready to move onto the next set of tasks in the next job. Similarly, it ’ s convenient to parse logs and test results and the Job level (or at the agent level, if you will). Test results are automatically aggregated by Bamboo into a single pass/fail report for the entire plan. You can then drill down into the various testing jobs . - requirements: not too granular, not too broad... nice middle ground for grouping Artifacts and requirements are handled at the job level because of the way jobs hold related tasks together. For example, it is assumed that if one batch of tests requires Artifacts are captured and consumed at the Job level (and we ’ ll talk more later on about why that is),
- So if we generalize that out, we get something this. The atomic unit in Bamboo is called a Plan. Plans are made up of one or more Stages; Stages are made up of one or more Jobs, and Jobs are made of up of one or more Tasks. Might seem like a lot of moving pieces, but they all have their purpose, which will become clear as we look at each of those elements in more depth. And look: build engineering is complicated. There ’ s just no getting around that. If it were easy, we wouldn ’ t need people to do the job that you guys are out there doing every day. Our job with Bamboo is to make your jobs suck less --hopefully a lot less.
- Finally, the Plan. The plan is your whole build pipeline from start to finish (and from here on out I ’ ll be referring to “ build pipelines ” as Plans). Plans can be triggered by changes to source control, they can be scheduled to run at certain intervals, or run only when a human comes along and pushes the “ go ” button. Plans can also have parent/child relationships, where the successful completion of the parent plan triggers the start of one or more child plans. (more on that later) Now, there are also some granular controls available at the Plan level. Basically, you can override a handful of global configs on a per-Plan basis to fine-tune them. Maybe you want to give certain users admin permissions, but only on one or two plans. Maybe you want to keep most build results around for 3 weeks, but for one particular Plan, you want to keep them longer. If you want to play around with these kinds of settings, the help docs will guide you through the mechanics of it.
- Don ’ t build alone: integration to deploy automatically to Heroku, connect with JIRA, get build notifications in HipChat, support for Cocoa, iOS, and XCode with lots of tasks recording OCUnit/SenTestKit results and keychain management. Add a task to upload directly to HockeyApp for crash reporting and testing.
- Don ’ t build alone: integration to deploy automatically to Heroku, connect with JIRA, get build notifications in HipChat, support for Cocoa, iOS, and XCode with lots of tasks recording OCUnit/SenTestKit results and keychain management. Add a task to upload directly to HockeyApp for crash reporting and testing.
- Don ’ t build alone: integration to deploy automatically to Heroku, connect with JIRA, get build notifications in HipChat, support for Cocoa, iOS, and XCode with lots of tasks recording OCUnit/SenTestKit results and keychain management. Add a task to upload directly to HockeyApp for crash reporting and testing.
- Don ’ t build alone: integration to deploy automatically to Heroku, connect with JIRA, get build notifications in HipChat, support for Cocoa, iOS, and XCode with lots of tasks recording OCUnit/SenTestKit results and keychain management. Add a task to upload directly to HockeyApp for crash reporting and testing.
- Don ’ t build alone: integration to deploy automatically to Heroku, connect with JIRA, get build notifications in HipChat, support for Cocoa, iOS, and XCode with lots of tasks recording OCUnit/SenTestKit results and keychain management. Add a task to upload directly to HockeyApp for crash reporting and testing.
- Don ’ t build alone: integration to deploy automatically to Heroku, connect with JIRA, get build notifications in HipChat, support for Cocoa, iOS, and XCode with lots of tasks recording OCUnit/SenTestKit results and keychain management. Add a task to upload directly to HockeyApp for crash reporting and testing.