Claudia Foglieni, Fabrizio Brancati - Keep calm and automate your mobile pipeline - Codemotion Milan 2018
•Download as PPTX, PDF•
0 likes•123 views
DevOps for the backend is easy, there are a lot of tools to do it, but what about mobile apps? We have successfully implemented an automated pipeline to build, test and deploy 3 different native applications for both iOS and Android. We also handle different signing certificates and provisioning profiles, multiple environments, custom JIRA integration and testers engagement. We will show you our approach with a complete working solution that we use every day.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Claudia Foglieni, Fabrizio Brancati - Keep calm and automate your mobile pipeline - Codemotion Milan 2018
Similar to Claudia Foglieni, Fabrizio Brancati - Keep calm and automate your mobile pipeline - Codemotion Milan 2018 (20)
More from Codemotion
More from Codemotion (20)
Recently uploaded
Recently uploaded (20)
Claudia Foglieni, Fabrizio Brancati - Keep calm and automate your mobile pipeline - Codemotion Milan 2018
- 1. Keep calm and automate your mobile pipeline Claudia Foglieni & Fabrizio Brancati Milan | November 29 - 30, 2018
- 2. Right Tools for Every Task Jenkins
- 3. Our Applications released in production by Fastlane & Jenkins Our Applications released by Fastlane & JenkinsOur Applications
- 4. Get Off to a Good Start Version your code in GIT Add info about your release Select the right scheme or flavor You can also include store details and graphical resources
- 5. Let’s See Some Code iOS Style
- 6. If You Want To… Manage Certificates PROS - Centralized repository with all the certificates - No more conflits when you generate a new certificate - Faster onboarding CONS - Removing Fastlane will be difficult
- 7. If You Want To… Manage Dependencies PROS - Dependencies consistency between each build even for different app versions - Notifications if a new update is available CONS - For Android it’s not directly integrated in Fastlane
- 8. Defining The Pipeline Personalize your app Configure your build Issue tracker Keep your team updated
- 9. Our Engine Is Like This
- 11. Configure Your Build iOS Style
- 12. Configure Your Build Android Style
- 13. Customize… JIRA Management Our solution • Plugin dedicated to JIRA • Ability to create custom releases • Ability to update an issue Solution on the market • No plugin with JIRA’s integration • No automatic transition of issues Our needs • Use JIRA internally • Keep a track of all the releases • Automatic issues update • Send updates about a release
- 15. Customize… Alert for Everyone Solution on the market • Plugin for Slack notification • Different solutions for sending custom emails Our needs • Alert our developers about issues on their branch • Send emails to our test team about new internal releases • Send information to the crowd team for beta release Our solution • Create a template for Slack, with all the needed information • Use the standard Jenkins plugin for email, with a custom template
- 17. Go Live & Beyond
- 18. Don’t Stop Me Now… We have a solution also for: • Integration with SonarQube for code analysis • Local server for automatic UI tests • Automatic commit and tagging after a release • And more… Stay tuned for the next Sisal Talk at the next event! Find us at Sisal Stand *we have gadgets*
- 19. All images are from Freepik Credits & Links https://fastlane.tools https://jenkins.io https://it.atlassian.com/software/jira https://slack.com https://www.ruby-lang.org http://groovy-lang.org https://github.com/sumoheavy/jira-ruby
Editor's Notes
- C: Every Friday evening a developer know that 6 pm is the most dangerous hour. Your partner is waiting for you at home, your friends are waiting for you at the local pub and your boss can come to you in any moment to request a new release. Every release is a fight about compiling, merging, tagging, deploying and it needs a lot of time. This is a waste of time: the operation are always the same, the flow is error prone and if something dosen't work as expected you need to restart the process. Do you know that you can release your app in 1 minute, clicking on a simple button?
- F: Our solution to simplify our life, and survive at work, is to use two different tools: Jenkins and Fastlane. Jenkins is like an housekeeper, that coordinates all the activities in a release. It can alert you about the status of your build and the currently executing phase. It also offers information about the time needed to complete all the operations and if there are other releases in the build queue. Fastlane is the delegate that receive all the request and execute the right task. Every task can be split in sub tasks, with parameters that can personalize the flow of the operations. If you have a task related to a mobile app, Fastlane can handle it with minimal configuration. Do you know that the configuration for Jenkins and the previous code for Fastlane must be commited in your repository? Both has a dedicated file with all the code: Jenkinsfile and Fastfile. How do we know that these tool scan help a developer to save time?
- C: Our main focus in our team at Sisal are three applications: SisalPay, allows users to pay Italian bills, phone recharges and Public Administration payments Bill, a new digital payment system with a consumer e-wallet Bill Business, merchant version for accepting Bill payments They use different payment gateways, with different functionalities and graphical resources. In our configuration Fastlane&Jenkins manage these different applications. The main flow in Jenkins to build them is the same. Every task in Fastlane is personalized based on the app needs. Our solution can help you in this case: you can maintain a standard procedure with macro steps and insert a personalized tasks in the right place. Fastlane&Jenkins release them also in production. But how do we do it?
- F: The first step is the most simple and we hope that you are already using it: version you code in GIT. In Sisal we follow the Git Flow Workflow. In this way we can choose to build only the right branches that contain our release and distribute our apps. The other branches are tested automatically by Fastlane&Jenkins to catch build problems or error earlier. Every release needs some information about the fixes and functionalities. If the build is internal, for example for testing, is important to add the list of the changes. In this way you can help your test team to understand the main focus of the new build. If you have different environments you need a build with the right scheme or flavor. Our solution give you the ability to choose where you want to deploy your app with a simple parameter. When you need to release a new build in production there is another step. You can automatically update your official page on the App Store and Google Play with screenshots and release notes. Your marketing team will appreciate it!
- F: Here you can find an extract of our solution. Fastlane is open source and is written in Ruby. In green you can find three main functions in our workflow in Fastlane. The first one is about the version of Xcode. You must choose the right version or the default one will be used. You can personalize the version for every app, in order to change it as you want. In this way you can try new versions of Xcode before distribute it. The second one build your app with the right workspace and scheme. It also clean your derived data before build it. The last step deploy your app to the store by specifying some parameters like: App version, disable automatic release in order to always control when the final user will receive the new app, update screenshots and wait for submitting to Apple. Now you have a basic pipeline that build and deploy your app.
- C: Now you can add some features like certificates management, a big pain for every developer. If you have a big team or a distributed one, handling the certificates can be difficult. You can easy up the new developer onboarding by using Match, a tool included in Fastlane. Match will handle all the cerfiticates management for your team. You just need to give it access to your Developer Account, create a private repository and give Match the rights to access it and it will encrypt all your certificates. As a con, removing Fastlane for Certificate Management will be difficult. As you can see to use your certificates inside a build you can just add one function with four parameters: The private repository URL, the certificate type, it can be ”appstore” or “development”, in this case we used “appstore” to be able to deploy our app to the Store, the app identifier and set it to readonly to do not overwrite the existing ones if expired.
- C: Another interesting feature is automatic dependency management. We hope that you are currently using a depencendy manager, because the manual handling will make you loose a lof of time. With this solution you can also alert your developers when a new version is available. As a con, for Android if you have a private repository for your dependencies you need to execute a gradle task to install them. How can you handle all this things? As you can see for iOS you can use CocoaPods to install your dependencies in your app. You can also use Carthage if you want. On the other side, for Android, you have to execute the gradle task that we talked earlier.
- F: In order to implement our pipelane, we have create a sequence of four steps, that is executed every time we need a release. We used Jenkins for doing that and you can configure it for your specific needs, adding or removing every single step. Every line can be mandatory, optional or precompiled with constant values. Our suggestion is to calibrate it with a default configuration, that is the most used. In this way you will have a faster release. Our first step is about the app personalization: You can choose the release type, build for just building the app, test to upload it to TestFlight or Google Play’s in the internal or alpha or beta tracks, and release to upload on to App Store or Google Play’s production track. The second step is about configuring your build: You can set the build version and the build number, this is very useful because both the Store doesn’t allow to upload the same build version twice. The third step is about issue tracker: Here you can set your username and password to be able to notify the assignee that a new build is ready for testing. The last step is about the mailing list and the changelog: We want to notify more than one people inside the company, and to solve that problem we send a custom release email to everyone that is inside this mailing list. We also include a changelog in this email, and the same changelog is also used on the Stores.
- F: Our implementation is different from Fastlane, in fact Jenkins is also open source but it uses Groovy as scripting language. As a first step, we define a pipeline and the agent, a Mac in this case. An agent is the computer where the build needs to be executed. Then we define a list of parameters, you can set different types: Every CHOISE is a select inside the form, every STRING is an input and PASSWORD is to hide it in the build logs. Jenkins will add the all the parameters to the environment so you don’t need to send username and password to Fastlane directly, he can take it from the environment. Every build can have different stages to split the code in logical blocks. Here you can find an example named “Build” that will execute a personalized script. This is the most important line of the script, it will execute Fastlane with some custom parameters, the same that we added in the ”parameters” section.
- C: As we know, iOS and Android have different Stores, but the step an nearly the same. You can choose in both cases to upload the build for testing or for production, by using TestFlight or testing tracks for Google Play. You will find all the parameters in the «options» object, is the how Fastlane handles lane parameters. To use the right scheme or flavor of your app, you need to add some logic to switch between them. In this case we have different schemes or flavors for every environment that we need. At last you can also personalize you icon by adding a «Alpha» or «Beta» badge on it, in this way you can rapidly understand if your app is for testing or for production.
- F: For iOS to be able to set different build versions and build numbers we created two custom lanes that read and write the main app plist file to the desired ones. Since Fastlane uses Ruby, you can use all the available Ruby functions inside your Fastfile. For example here we use the File class to read and write files. We also used regex string replace to set the version and build numbers.
- F: Instead, for Android, we extracted the app version and build from the build.gradle and we added it to the gradle.properties file. This allowed us to easily update them with two simple string replaces.
- C: We hope that every team has an issue tracker, at Sisal we use JIRA. We need to track now only bug, features or improvements, but also the releases. We also want to automate this manual step by creating, updating and send notifications about every release. There is a plugin for Fastlane for JIRA, but it doens't fit our needs, it only update issues, and there isn't an automatic transition of issues. JIRA has REST APIs, so we decided to create a Fastlane plugin to handle it. This plugin give us the ability to create and edit every field of an issue and to also update their status.
- C: To create this plugin, we use an open source dependency, "jira-ruby". Then we define some basic options, like JIRA website, username and password to create the connection. We suggest you to use a dedicated to account to do it, and to add it to the enviroment variables. The "jira-ruby" package has some useful APIs, like searching for an issue by using Jira Query Language. This is an example on how make a transition of an issue from the "Ready for Deploy" status to a "Ready for Testing" status.
- F: Every team should update their members about issue on their braches. It should also update other teams about new releases when available. Fastlane natively supports Slack, but there are different solutions for sending email out there. We decided to go natively by using Slack for sending notifications inside the company, and to use the standard email support with a custom template for Jenkins.
- F: These are two examples of Slack notifications made by our integration. One for an errored build and one for a succesful build. As you can see you can add some useful informations like the error and lane where it happened, the build branch, the commit author and the commit message.
- F: Now, the final step. Release the app to TestFlight, AppStore or Google Play. For TestFlight you can set the changelog and directly distrubute it to external groups. For App Store is the same that we saw before, with app version, automatic release, screenshots and submission. For Google Play you can choose every track, even custom ones, and the rollout percentage, fifty percent in this case. You can also define a custom APK path, but we choose to use the gradle default one.
- C: These were the main steps to create a fully functional release. We have done a lot more things like integrating SonarQube for code analysis, launch a local server before executing UI tests, automatic commit and tagging in GIT after a relase and more. Stay tuned for more Sisal Talks! Find us at the Sisal stand, we also have gadgets! I'm Claudia Foglieni, Lead Mobile Architet and I hope that our talk can help your team F: I'm Fabrzio Brancati, Mobile Architet and don't be shy and ask us anything, do you have any question?