SOASTA Webinar: Process Compression For Mobile App Dev 120612
•Download as PPT, PDF•
1 like•1,010 views
1. The webinar discussed continuous integration and automation practices for mobile development and testing. It focused on how to automate testing to keep up with the pace and scale of mobile development. 2. Speakers from Atlassian, Zephyr, and SOASTA discussed how tools like Bamboo and CloudTest can help automate builds, testing, and monitoring to fail faster and achieve continuous delivery of mobile apps. 3. The webinar emphasized that manual testing cannot keep up with the pace of mobile development and highlighted principles of continuous integration like building and testing code frequently and leveraging automation.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
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. 1Webinar Presents Continuous Integration and Automation for Mobile Development & Test
- 2. 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
- 3. 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
- 4. 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
- 5. 5 Fingers and Eyeballs VS. Pace and Scale of Mobile Development
- 6. 6 SDLC tasks are a constant. Pace Isn’t
- 7. 7 The Mobile Need is Elementary > More Progress in Less Time <
- 8. 8
- 9. 9 We help plan, build, and launch great software Team Collaboration Track projects, events, & people Group Chat Track, Plan, Analyze Agile project tracking Exploratory Testing ...and more! • 23,000 customers in over 130 countries • Offices in Sydney, San Francisco & Amsterdam • A “leader” in ALM according to Gartner
- 11. Why does Continuous Integration matter? Find bugs faster Make merging suck less Faster feedback loops Less lag time x 2 for Mobile
- 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. 14 What does a CI tool do? Clone repo Build Unit Tests Deploy to QA UI Tests Integration Tests API Tests Performance/Load Tests Deploy to Production Smoke tests
- 15. 15 Plan
- 19. 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
- 21. 21 JobsJobs Jobs run in parallel inside their container: a Stage • 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
- 23. 23 PlansPlans • 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
- 24. 24 Up your Mobile Dev speed 1. Start failing faster
- 25. 25 Up your Mobile Dev speed 1. Start failing faster 2. Don’t build alone
- 26. 26 Up your Mobile Dev speed 1. Start failing faster 2. Don’t build alone 3. Atlassian <3 mobile devs
- 27. 27 Up your Mobile Dev speed 1. Start failing faster 2. Don’t build alone 3. Atlassian <3 mobile devs Blog: http://atlss.in/mobileCI
- 28. 28 Up your Mobile Dev speed 1. Start failing faster 2. Don’t build alone 3. Atlassian <3 mobile devs Blog: http://atlss.in/mobileCI
- 29. 29 Up your Mobile Dev speed 1. Start failing faster 2. Don’t build alone 3. Atlassian <3 mobile devs Blog: http://atlss.in/mobileCI
- 30. 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
- 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 •3 Centralize your test assets •Single test repository •Accessible and useable globally •Manual, automation and performance
- 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 •5 Accessibility to entire Project Team Metrics Availability 24 x 7 Real-time updates
- 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. 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
- 42. 42 Functional Test Automation Real User Monitoring Performance & Load Testing Development & Build Application Application Development Lifecycle
- 43. 43 Application Development Lifecycle Application TouchTest CloudTestmPulse mobile v Development & CI
- 44. 44
- 45. 45 Source Code Repository Devs Build Server Check out Test Results Check in Run Tests Unit Tests ☐ Pass ☐ Fail ✓ To QA or Users
- 46. 46 Source Code Repository Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent Devs To or Beta Users
- 47. 47 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 48. 48 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 49. 49 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 50. 50 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 51. 51 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 52. 52 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 53. 53 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 54. 54 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 55. 55 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 56. 56 Source Code Repository Devs Real Devices Bamboo Build Server Check out Test Results Check in Push to devices In parallel Run Tests Execute on devices ☐ Pass ☐ Fail ✓ Bamboo Mac Agent To or Beta Users
- 57. 57 • No jailbreak required • No tethering required • iOS 5.0, 5.1, 6.0 • iPhone 3GS, 4, 4S, and 5 • iPad 1, 2, 3, 4 • iPad mini • Simulators • No “rooting” required • No tethering required • Android 2.3.3 (Gingerbread) and later • Phones, tablets, and emulators
- 58. 58 • Download CloudTest Lite (http://www.soasta.com) • Includes TouchTest technology • Free for a single device • No expiration • Free support via CloudLink forums
- 59. 59 It Doesn’t Matter Where You Start. JUST START!
- 60. 60 Q&A Contact SOASTA: info@soasta.com 866.344.8766 Follow us: twitter.com/cloudtesttwitter.com/cloudtest facebook.com/cloudtestfacebook.com/cloudtest Knowledge Center •White Papers •Webinar Recordings •Case Studies CloudLink Community •Support •Tutorials •Video RESOURCES www.SOASTA.com www.Atlassian.comwww.GetZephyr.com Products •Zephyr Enterprise •Zephyr Community •Zephyr for JIRA Support Center •Knowledge Base •ZephyrTV •Community Forums
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.