Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
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
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
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
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
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
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
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
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
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
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.