Tag: continuous integration

Webinar: Best Practices for Mobile CI – Sauce Labs

Hey guys, today I will post a webinar that I joined last week about Mobile CI.

It is very interesting, so you will see briefly when you need to use, why, how it works, etc. It lasts 43 minutes so, make sure that you have time to watch. Jump to 00:27:35 to watch the demo of Sauce Labs.

To download or watch you need follow the instructions in the link below:

https://saucelabsreview.webex.com/saucelabsreview/lsr.php?RCID=06e87f252b274b37b4500335b35ef868

 

What is CI for mobile ?

Screen Shot 2015-05-28 at 10.45.39

Automatically – every commit

How does it works?

Screen Shot 2015-05-28 at 10.46.57

Why ?

– Reduce the need for human-based testing (Save money and time)

– Faster Feedback

– Automate Everything (Very optimistic point of view)

– No touch configuration

– Automated OTA Distribution

– Code Validation: Automated Builds and Tests

 

How choose the right process ?

Screen Shot 2015-05-28 at 10.53.00

 

 

Depend the size of the

company.

 

 

Mobile is harder

– Infrastructure (If you are building in iOS – You will need XCode, a MacMini, etc.)

– Compilation/Code Signing (You have to configure your build machine, so you will need your key store file, mobile provisioning…)

– Testing (What is the right time to use, challenge to choose what is the better for the project- real devices, simulators…)

– Deployment

 

Simulators x Emulators x Devices

Simulators

– Used by iOS, included w/ XCode

– Execute i386 instruction set, not ARM

– Upside: Very fast compared to Emulators

– Downside : You don’t have access hardware functions (GPS,Bluetooth Radio, Accelerometers,etc)

Emulators

– Used by Android, included with Android sdks

– Execute ARM (or native device instruction set)

– Upside: You can find free tools

– Downside: Very slow compared to Simulators

– Do not have access to certain hardware functions (GPS, Bluetooth Radio, Accelerometers, etc)

Devices

– Upside: Reproduces the actual performance experienced by your users

– Upside: The only way to catch manufacturer/OEM bugs

– Downside: Very expensive to configure and maintain compared

– Upside: Full access to hardware functions (GPS, Bluetooth Radio, Accelerometers, etc)

 

When to use devices vs simulators/emulators ?

– Emulators and Simulators are an excellent solution for running automated tests during development. They are inexpensive and will reliably catch most problems.

– Physical Devices can be used on a lower frequency (i.e. pre-release, weekly, daily, etc.). They are the only way to catch performance problems, test certain hardware features and find OEM issues. In the least, devices should be used before every release.

 

Unit Testing

– 77% of developers said app quality is “very important or mission critical”

– 80% of mobile developers test their apps manually

– Only 13% of mobile developers use automated testing

 

Unit vs Functional

– Unit: Testing small pieces of code

– Functional: Testing button clicks and UI interaction

Benefits:

– Instant Gratification !

– Repeatable

– Can automatically test every commit

Challenges:

– Unit Tests are not users

– Lot of work to write and maintain them

Which framework to use ?

– You need to remember:

– What is the language/framework do your developers know

– Open Source/Community Support

– 3rd party framework requirements

 

CI Tools/Services for mobile

– Jenkins:

Open Source, Lots of plugins, iOS and Android 

 Self-Hosted, DYI solution (Setup all the environment, it isn’t easy this part)

– Travis CI:

Hosted Solution, OS X support, lots of plugins, iOS and Android 

Tedious setup process

– Ship.io:

Hosted solution, Designed specifically for mobile, Easy setup, iOS and Android 

Less flexible than other solutions

– Xcode CI:

Integrated w/ Xcode, Apple-Supported

Self-hosted, iOS Only

Thank you guys, thank you Sauce Labs ! Hope you like it !

Why use continuous integration

Integrate at least daily

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

By integrating regularly, you can detect errors quickly, and locate them more easily.

 

Solve problems quickly

Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.

Continuous Integration is cheap. Not continuously integrating is costly. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

Continuous Integration brings multiple benefits to your organization:

  • Say goodbye to long and tense integrations
  • Increase visibility which enables greater communication
  • Catch issues fast and nip them in the bud
  • Spend less time debugging and more time adding features
  • Proceed in the confidence you’re building on a solid foundation
  • Stop waiting to find out if your code’s going to work
  • Reduce integration problems allowing you to deliver software more rapidly

More than a process

Continuous Integration is backed by several important principles and practices.

The Practices

  • Maintain a single source repository
  • Automate the build
  • Make your build self-testing
  • Every commit should build on an integration machine
  • Keep the build fast
  • Test in a clone of the production environment
  • Make it easy for anyone to get the latest executable
  • Everyone can see what’s happening
  • Automate deployment

How to do it

  • Developers check out code into their private workspaces.
  • When done, the commit changes to the repository.
  • The CI server monitors the repository and checks out changes when they occur.
  • The CI server builds the system and runs unit and integration tests.
  • The CI server releases deployable artefacts for testing.
  • The CI server assigns a build label to the version of the code it just built.
  • The CI server informs the team of the successful build.
  • If the build or tests fail, the CI server alerts the team.
  • The team fix the issue at the earliest opportunity.
  • Continue to continually integrate and test throughout the project.

Team Responsibilities

  • Check in frequently
  • Don’t check in broken code
  • Don’t check in untested code
  • Don’t check in when the build is broken
  • Don’t go home after checking in until the system builds

Many teams develop rituals around these policies, meaning the teams effectively manage themselves, removing the need to enforce policies from on high.

Continuous Deployment

Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests.

Essentially, “it is the practice of releasing every good build to users,” explains Jez Humble, author of Continuous Delivery.

By adopting both Continuous Integration and Continuous Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working software.

With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fuelling real change in your organisation, and turning your release process into a business advantage.

 

Font: http://www.thoughtworks.com/continuous-integration

Continuous integration

Nowadays we talk a lot about Continuous Delivery (CD), and there is a good reason for that. In the same way that developing code driven by tests was a defining change in the past few years, the practice of releasing new versions of a system continually is becoming the next big thing.

However, though there are a lot of tools to help you implement CD, it is no simple task. In this post I’ll walk you through how the team I’m on is implementing CD using automation as the first step to our goal.

The Problem

Initially, the deployment process on the project was basically manual. Although we had a document with the task details, almost every time the deployment failed, it was necessary to have some experienced person identify issues and solve them. Besides that, the document changed at each iteration, to accommodate modifications to scripts that had to be run to fix issues. This made the process even more chaotic.

Another big issue was that by being super fragile, the process was very time consuming and the deployment had to happen during a low system utilization period. Which meant that the team had to update the system with the new features at night. Final straw! The team decided to invest in improving this process. And when I say “the team” I really mean across all project roles, and not only the group of developers. We collectively researched what could be improved and how to implement the fixes. Working together with the project managers and the client was critical to providing senior management with visibility of the problem. It then stopped being a team issue and became a company-wide issue.

To give a little bit of context about the project, the codebase is about 6 or 7 years old and was started with one of the first versions of the Rails framework. Today we are using Ruby 1.8 and Rails 2.3. The production environment is located in a private data center and has more than 20 boxes dedicated to run the web server, database and so on. All configuration changes are made by Puppet, which is run at every deployment. The team has a 3-week iteration and we deploy at the end of each iteration.

Solution: Take 1

The first step of improvements was to try to automate the deployment process. Depending on a manual process that is constantly changing was the biggest problem. We set off making the deployment to be as simple as running a one-line script. The automation started right from getting the Git tag for the correct version to be deployed to triggering specific scripts that had to be run at every iteration transparently. At the end of the first improvement phase, the team had a deploy script that with a simple command line would do all the system state validations, update the code and database and verify that it was in a consistent state. However, even with an automated script, the process was still unreliable. We often had to complete the deployment manually due to failures in the run.

Solution: Take 2

Then we started the second phase of improvements – we changed the entire deploy script, splitting the process into steps, where every step was atomic. Thus, in case of a failure we didn’t have to restart the whole process, just from the failed step onwards. This change helped reduce the complexity and made it a lot faster. We also investigated the common deployment issues and fixed them for good.

Result?

The deployments that usually averaged 5 to 6 hours, with a maximum of 10 hours, were down to 2 hours at the end of the two improvement phases. The project and company management were thrilled and this further boosted the team’s morale.

The next steps on our Continuous Delivery journey, will be to split code, data and infrastructure changes, so it will be possible to release new versions with no system downtime. There are a lot of techniques to help with that, and right now we are investigating the context so that we can chose the solution that will be the best fit for us. Stay tuned for more…

 

Font: http://www.thoughtworks.com/insights/blog/automacao-como-pontape-inicial-para-entrega-continua