Tweet
Tweet

Slide 1

Slide 1 text

Jordan Terry — Senior Android Engineer at Marks & Spencer - @jordanterry Developer Productivity On a Budget Adam Ahmed - Senior Android Engineer at TravelPerk — @oheyadam

Slide 2

Slide 2 text

Background

Slide 3

Slide 3 text

Background •We both work on Platform/Foundations teams

Slide 4

Slide 4 text

Background •We both work on Platform/Foundations teams •Mid-sized mobile orgs (30+ Engineers)

Slide 5

Slide 5 text

Background •We both work on Platform/Foundations teams •Mid-sized mobile orgs (30+ Engineers) •Our teams’ focus is improving developer productivity

Slide 6

Slide 6 text

Background •We both work on Platform/Foundations teams •Mid-sized mobile orgs (30+ Engineers) •Our teams’ focus is improving developer productivity •The things we’ll talk about were born of necessity to our organizations

Slide 7

Slide 7 text

What We’ll Cover

Slide 8

Slide 8 text

What We’ll Cover •Automating bug reporting and triaging

Slide 9

Slide 9 text

What We’ll Cover •Automating bug reporting and triaging •Rolling out convention plugins

Slide 10

Slide 10 text

What We’ll Cover •Automating bug reporting and triaging •Rolling out convention plugins •Automating our release trains

Slide 11

Slide 11 text

What We’ll Cover •Automating bug reporting and triaging •Rolling out convention plugins •Automating our release trains •Reporting build times

Slide 12

Slide 12 text

What We’ll Cover •Automating bug reporting and triaging •Rolling out convention plugins •Automating our release trains •Reporting build times •Improving our CI workflows

Slide 13

Slide 13 text

What We’ll Cover •Automating bug reporting and triaging •Rolling out convention plugins •Automating our release trains •Reporting build times •Improving our CI workflows •Linting!

Slide 14

Slide 14 text

Automating bug reporting and triaging @oheyadam

Slide 15

Slide 15 text

What was the problem here? @oheyadam

Slide 16

Slide 16 text

What was the problem here? •Different squads own different parts of the code-base @oheyadam

Slide 17

Slide 17 text

What was the problem here? •Different squads own different parts of the code-base •We wanted a way to immediately find out when a crash happens @oheyadam

Slide 18

Slide 18 text

What was the problem here? •Different squads own different parts of the code-base •We wanted a way to immediately find out when a crash happens •Each squad has their own Jira board @oheyadam

Slide 19

Slide 19 text

What did we try? @oheyadam

Slide 20

Slide 20 text

What did we try? •Crashlytics Jira integration @oheyadam

Slide 21

Slide 21 text

What did we try? •Crashlytics Jira integration •Slack notifications @oheyadam

Slide 22

Slide 22 text

What did we try? •Crashlytics Jira integration •Slack notifications •Assigning fire-fighters @oheyadam

Slide 23

Slide 23 text

What did we try? •Crashlytics Jira integration •Slack notifications •Assigning fire-fighters •Rolling out our own tool! @oheyadam

Slide 24

Slide 24 text

What does it do? @oheyadam

Slide 25

Slide 25 text

What does it do? •Runs as a cron job @oheyadam

Slide 26

Slide 26 text

What does it do? •Runs as a cron job •Checks if there are any new crashes @oheyadam

Slide 27

Slide 27 text

What does it do? •Runs as a cron job •Checks if there are any new crashes •Parses stack-traces and figures out who the owner is @oheyadam

Slide 28

Slide 28 text

What does it do? •Runs as a cron job •Checks if there are any new crashes •Parses stack-traces and figures out who the owner is •Talks to OpenAI to try to suggest a solution @oheyadam

Slide 29

Slide 29 text

What does it do? •Runs as a cron job •Checks if there are any new crashes •Parses stack-traces and figures out who the owner is •Talks to OpenAI to try to suggest a solution •Opens a detailed Jira ticket on their board @oheyadam

Slide 30

Slide 30 text

What does it do? •Sends them a Slack notification @oheyadam

Slide 31

Slide 31 text

What does it do? •Sends them a Slack notification •Allows us to customize bug reporting logic for teams @oheyadam

Slide 32

Slide 32 text

What does it do? •Sends them a Slack notification •Allows us to customize bug reporting logic for teams •Allows us to do the same for other tools like Datadog @oheyadam

Slide 33

Slide 33 text

What does it do? •Sends them a Slack notification •Allows us to customize bug reporting logic for teams •Allows us to do the same for other tools like Datadog •Works for both platforms @oheyadam

Slide 34

Slide 34 text

@oheyadam

Slide 35

Slide 35 text

Convention plugins @jordanterry

Slide 36

Slide 36 text

Problem Build configuration contained large amounts of copy and pasted duplication. As we modularised more, this would become a maintenance problem. @jordanterry

Slide 37

Slide 37 text

Solution The platform team wanted to ensure we could scale our build configuration to achieve our modularisation goals. To achieve this, we adopted Gradle convention plugins. @jordanterry

Slide 38

Slide 38 text

State of the build files @jordanterry

Slide 39

Slide 39 text

State of the build files @jordanterry compileOptions { sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 }

Slide 40

Slide 40 text

State of the build files @jordanterry compileOptions { sourceCompatibility '1.8' targetCompatibility '1.8' }

Slide 41

Slide 41 text

State of the build files @jordanterry plugins { id 'com.android.library' id 'org.jetbrains.kotlin.android' }

Slide 42

Slide 42 text

State of the build files @jordanterry android { compileSdkVersion rootProject.compileSdkVersion defaultConfig { minSdkVersion rootProject.minSdkVersion targetSdkVersion rootProject.targetSdkVersion } }

Slide 43

Slide 43 text

State of the build files @jordanterry • Duplications

Slide 44

Slide 44 text

State of the build files @jordanterry • Duplications • Inconsistencies

Slide 45

Slide 45 text

State of the build files @jordanterry • Duplications • Inconsistencies • Crucial applied scripts

Slide 46

Slide 46 text

State of the build files @jordanterry • Duplications • Inconsistencies • Crucial applied scripts • Maintenance headaches

Slide 47

Slide 47 text

The Goal plugins { alias(libs.plugins.mns.android.application) } @jordanterry

Slide 48

Slide 48 text

The Goal plugins { alias(libs.plugins.mns.android.application) } android { namespace = “com.mns.some.module” } @jordanterry

Slide 49

Slide 49 text

The Goal plugins { alias(libs.plugins.mns.android.application) } android { namespace = “com.mns.some.module” } dependencies { implementation(libs.some.dependency) } @jordanterry

Slide 50

Slide 50 text

The two types of convention - Script import com.android.build.gradle.LibraryExtension plugins { id("com.android.library") kotlin("android") } // Configure Android configuration, including extensions.getByType().apply { compileSdk = 33 defaultConfig { setMinSdkVersion(23) setTargetSdkVersion("33") testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner" } compileOptions { targetCompatibility = JavaVersion.VERSION_1_8 sourceCompatibility = JavaVersion.VERSION_1_8 } kotlinOptions { jvmTarget = JavaVersion.VERSION_1_8.toString() } } @jordanterry

Slide 51

Slide 51 text

The two types of convention - A plugin class KotlinAndroidLibraryPlugin : Plugin { override fun apply(target: Project) { with(target) { pluginManager.apply("com.android.library") pluginManager.apply("org.jetbrains.kotlin.android") // Configure Android configuration. extensions.getByType().apply { compileSdk = ANDROID_COMPILE_SDK lint { @Suppress("UnstableApiUsage") baseline = file("baseline-lint.xml") } configureAndroidExtension(ANDROID_MIN_SDK, ANDROID_TARGET_SDK) } configureJavaJvm(JAVA_LANGUAGE_VERSION) configureKotlinJvm(JAVA_LANGUAGE_VERSION) configureJunit() configureSpotless() configureJacocoAndroid(extensions.getByType()) } } } @jordanterry

Slide 52

Slide 52 text

What were the benefits? @jordanterry

Slide 53

Slide 53 text

What were the benefits? • Removed 1,000s of lines of build configuration from the project @jordanterry

Slide 54

Slide 54 text

What were the benefits? @jordanterry

Slide 55

Slide 55 text

What were the benefits? • Removed 1,000s of lines of build configuration from the project • We can roll out new build features with low effort @jordanterry

Slide 56

Slide 56 text

What were the benefits? @jordanterry

Slide 57

Slide 57 text

What were the benefits? • Removed 1,000s of lines of build configuration from the project • We can roll out new build features with low effort • We have unit tests, functional and integration tests for our builds

Slide 58

Slide 58 text

What were the benefits? @jordanterry

Slide 59

Slide 59 text

State of a build file now plugins { alias(libs.plugins.mns.android.library) } android { namespace = "com.marksandspencer.androidfeatureflaglib" testOptions { unitTests { isReturnDefaultValues = true } } } dependencies { implementation(project(":data:logging:api")) implementation(libs.coroutines) implementation(libs.lifecycle.common.java8) testImplementation(project(":testutils")) testImplementation(libs.bundles.junit5.kotlin) testImplementation(libs.arch.core.testing) testImplementation(libs.mockk) testImplementation(libs.truth) testImplementation(libs.coroutines.test) testRuntimeOnly(libs.bundles.junit5.runtime) }

Slide 60

Slide 60 text

Step by step? - Move to a script import com.android.build.gradle.LibraryExtension plugins { id("com.android.library") kotlin("android") } // Configure Android configuration, including extensions.getByType().apply { compileSdk = 33 defaultConfig { setMinSdkVersion(23) setTargetSdkVersion("33") testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner" } compileOptions { targetCompatibility = JavaVersion.VERSION_1_8 sourceCompatibility = JavaVersion.VERSION_1_8 } kotlinOptions { jvmTarget = JavaVersion.VERSION_1_8.toString() } } @jordanterry

Slide 61

Slide 61 text

Step by step? - Move to a script import com.android.build.gradle.LibraryExtension plugins { id("com.android.library") kotlin("android") } // Configure Android configuration, including extensions.getByType().apply { compileSdk = 33 defaultConfig { setMinSdkVersion(23) setTargetSdkVersion("33") testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner" } compileOptions { targetCompatibility = JavaVersion.VERSION_1_8 sourceCompatibility = JavaVersion.VERSION_1_8 } kotlinOptions { jvmTarget = JavaVersion.VERSION_1_8.toString() } } @jordanterry

Slide 62

Slide 62 text

Lessons learned @jordanterry

Slide 63

Slide 63 text

Lessons learned • Evangelise for idiomatic Gradle concepts @jordanterry

Slide 64

Slide 64 text

Lessons learned • Evangelise for idiomatic Gradle concepts • Don’t keep your conventions in the build-logic module forever @jordanterry

Slide 65

Slide 65 text

Lessons learned • Evangelise for idiomatic Gradle concepts • Don’t keep your conventions in the build-logic module forever • Think carefully about what you include in your conventions @jordanterry

Slide 66

Slide 66 text

Who and why would benefit? @jordanterry

Slide 67

Slide 67 text

Who and why would benefit? @jordanterry •The smaller development team • Ease modularisation growing pains

Slide 68

Slide 68 text

Who and why would benefit? @jordanterry •The medium sized development team • More devs can do their work without worrying about build configuration • Helps the devs help the business

Slide 69

Slide 69 text

Who and why would benefit? @jordanterry •The larger team • Why don’t you have a platform team?

Slide 70

Slide 70 text

Other resources

Slide 71

Slide 71 text

Other resources •Herding Elephants - https:// developer.squareup.com/blog/herding- elephants/

Slide 72

Slide 72 text

Other resources •Herding Elephants - https:// developer.squareup.com/blog/herding- elephants/ •Stampeding Elephants - https:// developer.squareup.com/blog/stampeding- elephants/

Slide 73

Slide 73 text

Other resources •Herding Elephants - https:// developer.squareup.com/blog/herding- elephants/ •Stampeding Elephants - https:// developer.squareup.com/blog/stampeding- elephants/ •Now in Android - https://github.com/ android/nowinandroid

Slide 74

Slide 74 text

Other resources •Herding Elephants - https:// developer.squareup.com/blog/herding-elephants/ •Stampeding Elephants - https:// developer.squareup.com/blog/stampeding-elephants/ •Now in Android - https://github.com/android/ nowinandroid •Idiomatic Android - https://github.com/jjohannes/ idiomatic-gradle

Slide 75

Slide 75 text

Other resources •Herding Elephants - https://developer.squareup.com/blog/ herding-elephants/ •Stampeding Elephants - https://developer.squareup.com/ blog/stampeding-elephants/ •Now in Android - https://github.com/android/nowinandroid •Idiomatic Android - https://github.com/jjohannes/ idiomatic-gradle •Gradle Docs - https://docs.gradle.org/current/userguide/ userguide.html

Slide 76

Slide 76 text

Automating our release trains @oheyadam

Slide 77

Slide 77 text

What was the problem? @oheyadam

Slide 78

Slide 78 text

What was the problem? Preparing for a new release is a lengthy manual process @oheyadam

Slide 79

Slide 79 text

Preparing for a new release is a lengthy manual process • Announce a code freeze @oheyadam

Slide 80

Slide 80 text

Preparing for a new release is a lengthy manual process • Announce a code freeze • Find and notify the release captain @oheyadam

Slide 81

Slide 81 text

Preparing for a new release is a lengthy manual process • Announce a code freeze • Find and notify the release captain • Notify everyone else in the mobile org @oheyadam

Slide 82

Slide 82 text

Preparing for a new release is a lengthy manual process • Announce a code freeze • Find and notify the release captain • Notify everyone else in the mobile org • Create a release branch, update version codes, download latest strings @oheyadam

Slide 83

Slide 83 text

Preparing for a new release is a lengthy manual process • Create a release branch, update version codes, download latest strings • Document the release version and notes somewhere @oheyadam

Slide 84

Slide 84 text

Preparing for a new release is a lengthy manual process • Create a release branch, update version codes, download latest strings • Document the release version and notes somewhere • Ensure tests pass and QA is done @oheyadam

Slide 85

Slide 85 text

Preparing for a new release is a lengthy manual process • Ensure tests pass and QA is done • Upload to Play Store @oheyadam

Slide 86

Slide 86 text

Preparing for a new release is a lengthy manual process • Ensure tests pass and QA is done • Upload to Play Store • Potentially have to repeat some of these steps if someone pushes to the release branch again, or wants to create a hot-fix @oheyadam

Slide 87

Slide 87 text

What did we do? @oheyadam

Slide 88

Slide 88 text

What did we do? Automate it! @oheyadam

Slide 89

Slide 89 text

Automate it! We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 90

Slide 90 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 91

Slide 91 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 92

Slide 92 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 93

Slide 93 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 94

Slide 94 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 95

Slide 95 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 96

Slide 96 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 97

Slide 97 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 98

Slide 98 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 99

Slide 99 text

We drive the release stages using Calendar events, Zapier, Fastlane, and our CI provider @oheyadam

Slide 100

Slide 100 text

Reporting build times @jordanterry

Slide 101

Slide 101 text

Problem How long do our builds take? @jordanterry

Slide 102

Slide 102 text

Problem How long do our builds take? ..err, I don’t know @jordanterry

Slide 103

Slide 103 text

Solution Build a plugin to report build data to our data engine. This data can now be used to build dashboards, or be directly used in our OKRs. @jordanterry

Slide 104

Slide 104 text

How? @jordanterry

Slide 105

Slide 105 text

How? @jordanterry

Slide 106

Slide 106 text

How? @jordanterry

Slide 107

Slide 107 text

How? - Gluing it together class ObservabilityPlugin : Plugin { override fun apply(target: Project) { val plugin = TalaiotBasePlugin() plugin.apply(target) target.extensions.configure(BaseExtension::class.java) { publishers { customPublishers(NewRelicBuildPublisher(…)) } } } } @jordanterry

Slide 108

Slide 108 text

Dashboarding! - Total build time @jordanterry

Slide 109

Slide 109 text

Dashboarding! - Time Spent @jordanterry

Slide 110

Slide 110 text

Dashboarding! - Successful Builds @jordanterry

Slide 111

Slide 111 text

Does this help developer productivity? @jordanterry

Slide 112

Slide 112 text

Does this help developer productivity? • Not directly @jordanterry

Slide 113

Slide 113 text

Does this help developer productivity? • Not directly • Dashboarding and alerting can act as a canary for bad changes, or celebrations for good changes @jordanterry

Slide 114

Slide 114 text

Does this help developer productivity? • Not directly • Dashboarding and alerting can act as a canary for bad changes, or celebrations for good changes • Data helps build a case for contributing time towards platform initiatives @jordanterry

Slide 115

Slide 115 text

The elephant in the room @jordanterry

Slide 116

Slide 116 text

The elephant in the room • Gradle Enterprise (Devlocity) is the best tool for this @jordanterry

Slide 117

Slide 117 text

The elephant in the room • Gradle Enterprise (Devlocity) is the best tool for this • Incredible insights into your builds @jordanterry

Slide 118

Slide 118 text

The elephant in the room • Gradle Enterprise (Devlocity) is the best tool for this • Incredible insights into your builds • https://gradle.com/develocity/ @jordanterry

Slide 119

Slide 119 text

Improving our CI workflows @oheyadam

Slide 120

Slide 120 text

What was the problem here? @oheyadam

Slide 121

Slide 121 text

What was the problem here? •CI builds take too long @oheyadam

Slide 122

Slide 122 text

What was the problem here? •CI builds take too long •PRs stay up for a long time @oheyadam

Slide 123

Slide 123 text

What was the problem here? •CI builds take too long •PRs stay up for a long time •Product iterations are slow @oheyadam

Slide 124

Slide 124 text

What was the problem here? •CI builds take too long •PRs stay up for a long time •Product iterations are slow •Mobile org doesn’t use the same CI provider as the rest of the company @oheyadam

Slide 125

Slide 125 text

What did we do? @oheyadam

Slide 126

Slide 126 text

What did we do? •Investigated our current CI setup @oheyadam

Slide 127

Slide 127 text

What did we do? •Investigated our current CI setup •Migrated to a different provider @oheyadam

Slide 128

Slide 128 text

What did we do? •Investigated our current CI setup •Migrated to a different provider @oheyadam

Slide 129

Slide 129 text

What did we do? •Investigated our current CI setup •Migrated to a different provider •CCI allowed us to tap into existing knowledge and infrastructure @oheyadam

Slide 130

Slide 130 text

What did we do? •Investigated our current CI setup •Migrated to a different provider •CCI allowed us to tap into existing knowledge and infrastructure •Utilized remote build cache on our CI @oheyadam

Slide 131

Slide 131 text

What did we do? •Utilized remote build cache on our CI @oheyadam

Slide 132

Slide 132 text

What did we do? •Utilized remote build cache on our CI •Utilized CI parallelism @oheyadam

Slide 133

Slide 133 text

What did we do? •Utilized CI parallelism @oheyadam

Slide 134

Slide 134 text

What did we do? •Utilized CI parallelism •Fan-out @oheyadam

Slide 135

Slide 135 text

What did we do? •Fan-out @oheyadam

Slide 136

Slide 136 text

What did we do? •Utilized CI parallelism •Fan-out •Removed any unnecessary steps / downloads @oheyadam

Slide 137

Slide 137 text

What did we do? •Utilized CI parallelism •Fan-out •Removed any unnecessary steps / downloads •Reduced the execution time of our PR checks by up to 80% @oheyadam

Slide 138

Slide 138 text

What did we do? •Reduced the execution time of our PR checks by up to 80% •Reduced the execution time of our nightly / E2E tests / release jobs by up to 60% @oheyadam

Slide 139

Slide 139 text

What did we do? •Reduced the execution time of our PR checks by up to 80% •Reduced the execution time of our nightly / E2E tests / release jobs by up to 60% •Happy, productive developers! @oheyadam

Slide 140

Slide 140 text

Linting! @jordanterry

Slide 141

Slide 141 text

Problem How can we make our code consistent? Whilst keeping the developer experience consistent? @jordanterry

Slide 142

Slide 142 text

Solution Lint everything! Adopt Spotless + KtLint, Android Linter, other tooling. @jordanterry

Slide 143

Slide 143 text

The goal @jordanterry

Slide 144

Slide 144 text

The goal • Reduce bike shedding in pull requests @jordanterry

Slide 145

Slide 145 text

The goal • Reduce bike shedding in pull requests • Keep the feedback loop as low as possible @jordanterry

Slide 146

Slide 146 text

The goal • Reduce bike shedding in pull requests • Keep the feedback loop as low as possible •Pick up as many issues as early as possible @jordanterry

Slide 147

Slide 147 text

Spotless + KtLint https://github.com/di ff plug/spotless/tree/main/plugin-gradle • Adopt Spotless Gradle plugin • Adopt KtLint • Highlights issues • Autofixes issues @jordanterry

Slide 148

Slide 148 text

Spotless + KtLint https://github.com/di ff plug/spotless/tree/main/plugin-gradle • Adopt Spotless Gradle plugin @jordanterry

Slide 149

Slide 149 text

Spotless + KtLint https://github.com/di ff plug/spotless/tree/main/plugin-gradle • Adopt Spotless Gradle plugin • Adopt KtLint • Highlights issues • Autofixes issues @jordanterry

Slide 150

Slide 150 text

How we rolled it out @jordanterry

Slide 151

Slide 151 text

How we rolled it out • Integrate Spotless into our conventions plugins @jordanterry

Slide 152

Slide 152 text

How we rolled it out • Integrate Spotless into our conventions plugins • Write some tests! @jordanterry

Slide 153

Slide 153 text

How we rolled it out • Integrate Spotless into our conventions plugins • Write some tests! • Roll out throughout codebase with a version bump @jordanterry

Slide 154

Slide 154 text

Android Linting @jordanterry

Slide 155

Slide 155 text

Android Linting http://googlesamples.github.io/android-custom-lint-rules/book.md.html • Baseline your project @jordanterry

Slide 156

Slide 156 text

Android Linting http://googlesamples.github.io/android-custom-lint-rules/book.md.html • Baseline your project • Upload the lint reports to the CI @jordanterry

Slide 157

Slide 157 text

Android Linting http://googlesamples.github.io/android-custom-lint-rules/book.md.html • Baseline your project • Upload the lint reports to the CI • Write your own lint rules @jordanterry

Slide 158

Slide 158 text

Linting Gradle? @jordanterry

Slide 159

Slide 159 text

Linting Gradle? • Lint your dependencies • Removing unused dependencies helps your project • Be aware of dependency changes @jordanterry

Slide 160

Slide 160 text

Linting Gradle? • Lint your dependencies • Removing unused dependencies helps your project • Be aware of dependency changes • Lint your Gradle plugins @jordanterry

Slide 161

Slide 161 text

Move to the IDE! @jordanterry

Slide 162

Slide 162 text

Move to the IDE! • Use IntelliJ’s built in functionality @jordanterry

Slide 163

Slide 163 text

Move to the IDE! • Use IntelliJ’s built in functionality • Find tooling that provides plugins @jordanterry

Slide 164

Slide 164 text

Move to the IDE! • Use IntelliJ’s built in functionality • Find tooling that provides plugins • IDEs have the quickest feedback loop @jordanterry

Slide 165

Slide 165 text

Move to the IDE! • Use IntelliJ’s built in functionality • Find tooling that provides plugins • IDEs have the quickest feedback loop • Change your CI to a validation tool @jordanterry

Slide 166

Slide 166 text

Why should you do this? @jordanterry

Slide 167

Slide 167 text

Who should do this? Everyone @jordanterry

Slide 168

Slide 168 text

We’re Hiring!

Slide 169

Slide 169 text

Thank you!