Jasper Pipeline

.md

Pipeline

The main Pipeline scheme for creating a release build for both platforms IOS and Android is mostly the same, excluding signing platform specification.

Staging Build

To create build for Staging(Dev):

1. Create a pull request and wait until the Github Actions have completed the flutter linter work and requested a developer review for your changes.

   • Before we push new changes to the dev branch, we must first run flutter analyze which analyzes code by linter rules. All lint rules in the project:

       - annotate_overrides
       - avoid_catching_errors
       - avoid_empty_else
       - avoid_escaping_inner_quotes
       - avoid_field_initializers_in_const_classes
       - avoid_init_to_null
       - avoid_null_checks_in_equality_operators
       - avoid_positional_boolean_parameters
       - avoid_private_typedef_functions
       - avoid_relative_lib_imports
       - avoid_return_types_on_setters
       - avoid_returning_null_for_future
       - avoid_returning_null_for_void
       - avoid_setters_without_getters
       - avoid_shadowing_type_parameters
       - avoid_single_cascade_in_expression_statements
       - avoid_type_to_string
       - avoid_types_as_parameter_names
       - avoid_unnecessary_containers
       - avoid_unused_constructor_parameters
       - avoid_web_libraries_in_flutter
       - await_only_futures
       - cancel_subscriptions
       - cast_nullable_to_non_nullable
       - control_flow_in_finally
       - directives_ordering
       - empty_catches
       - empty_constructor_bodies
       - empty_statements
       - exhaustive_cases
       - file_names
       - hash_and_equals
       - invariant_booleans
       - iterable_contains_unrelated_type
       - join_return_with_assignment
       - leading_newlines_in_multiline_strings
       - library_names
       - library_prefixes
       - list_remove_unrelated_type
       - missing_whitespace_between_adjacent_strings
       - no_adjacent_strings_in_list
       - no_duplicate_case_values
       - no_logic_in_create_state
       - no_runtimeType_toString
       - non_constant_identifier_names
       - null_closures
       - overridden_fields
       - package_names
       - package_prefixed_library_names
       - parameter_assignments
       - prefer_asserts_in_initializer_lists
       - prefer_collection_literals
       - prefer_conditional_assignment
       - prefer_const_constructors
       - prefer_const_constructors_in_immutables
       - prefer_const_declarations
       - prefer_const_literals_to_create_immutables
       - prefer_constructors_over_static_methods
       - prefer_contains
       - prefer_equal_for_default_values
       - prefer_final_fields
       - prefer_final_in_for_each
       - prefer_for_elements_to_map_fromIterable
       - prefer_function_declarations_over_variables
       - prefer_generic_function_type_aliases
       - prefer_if_elements_to_conditional_expressions
       - prefer_if_null_operators
       - prefer_initializing_formals
       - prefer_inlined_adds
       - prefer_interpolation_to_compose_strings
       - prefer_is_empty
       - prefer_is_not_empty
       - prefer_is_not_operator
       - prefer_iterable_whereType
       - prefer_null_aware_operators
       - prefer_spread_collections
       - prefer_typing_uninitialized_variables
       - prefer_void_to_null
       - provide_deprecation_message
       - recursive_getters
       - slash_for_doc_comments
       - sort_child_properties_last
       - sort_unnamed_constructors_first
       - test_types_in_equals
       - throw_in_finally
       - tighten_type_of_initializing_formals
       - type_annotate_public_apis
       - type_init_formals
       - unnecessary_await_in_return
       - unnecessary_brace_in_string_interps
       - unnecessary_const
       - unnecessary_getters_setters
       - unnecessary_new
       - unnecessary_null_aware_assignments
       - unnecessary_null_checks
       - unnecessary_null_in_if_null_operators
       - unnecessary_nullable_for_final_variable_declarations
       - unnecessary_overrides
       - unnecessary_parenthesis
       - unnecessary_raw_strings
       - unnecessary_statements
       - unnecessary_string_escapes
       - unnecessary_string_interpolations
       - unnecessary_this
       - unrelated_type_equality_checks
       - unsafe_html
       - use_full_hex_values_for_flutter_colors
       - use_function_type_syntax_for_parameters
       - use_late_for_private_fields_and_variables
       - use_rethrow_when_possible
       - use_setters_to_change_properties
       - use_string_buffers
       - valid_regexps
       - void_checks 
   

   more about linter rules

   After the linter is completed successfully, we run flutter tests which run all projects tests. If a test is failed, the pull request will be rejected. If all tests are successful, the changes in the branch will automatically be deployed on the staging environment.

   Note: We moved the linter and test runs from Codemagic to GitHub actions since issues in these stages should be identified before the build begins which reduces costs.

2. Merge pull request to dev branch, after this codemagic start deploying your build automatically.

3. Staging build will be uploaded to Slack inside qa-build-mobile.

4. QA team can download the build directly from the slack channel but before the user device should be added to codemagic QA team to create an Apple certificate.

Codemagic Setup - Staging

Specification\Pipeline for Staging build in codemagic:

1. Trigger codemagic:
   - on push - on pull request update - trigger only on branch dev

2. Build specification: - build with latest XCode\cocoapods\flutter stable versions - flutter mode profile - signed option automatically for both platform

3. Post Script: - Start script to bump application version automatically. Then push it to the repository with name {b_name}-{x.y.z}

4. Uploaded file: - uploaded build’s to slack

Release Build

To create build for Release:

1. We create a pull request from the dev branch which has already been tested to release-{x.y.z}.
2. After merging new changes to release-{x.y.z} Codemagic will start deploying your build automatically.
3. The new release build will be uploaded to Apple Store\Google Play automatically. Once published, all QA members receive an email notification..
4. After release QA team can download IOS build from TestFlight and the Android build from Google Play.
   • TestFlight team members setupped inside developer.apple.com program
   • Google Play build can be downloaded inside the Beta build-in console

Codemagic Setup - Release

Specification\Pipeline for Release build in codemagic:

1. Trigger codemagic:
   - on push - on pull request update - trigger only on branch release-{x.y.z}

2. Build specification: - build with latest XCode\cocoapods\flutter stable versions - flutter mode release - signed option automatically with our production keys which was setupped previously

3. Uploaded file: - uploaded build’s to Apple(TestFlight) \ Google(Google Play)

Common

• Any update to the application requires the new build to pass all steps.
• To download the developer build from Slack, the team member needs to be added to QA team inside Codemagic and receive the Apple certificate for an open application.
• Release build doesn't have the capability to change ENV(release API only).
• Staging(developer) app build has the ability to change API ENV inside the application. To do this he should tap 10 times on the "Welcome" screen before login.
• To build a release application the CI\CD needs to have installed the release keys for both platforms.
• Obfuscation isn't set up because it can increase app size (read more - https://docs.flutter.dev/deployment/obfuscate#obfuscating-your-app)

@followthemoney1 - Thank you for continuing to refine this. Some additional comments here

1. "Create pull request and await until Github Actions done flutter linter work and requested developer reviewed your changes too. " should be "Create a pull request and await until the Github Actions have completed the flutter linter work and requested a developer review for your changes. "
2. Is just the flutter analyze being done? What happens if the linter fails?
3. "Before we push developer changes to dev bransh, firstly we run flutter analyze which analyzes code by linter rules(I can send you all our rules if need). then we will run flutter tests which run all projects tests which we write before. If something from it dropped build pull requests weren’t passed so this changes didn’t push to branch or build. Note: We moved all linter and tests from codemagic stage to the code review stage because it is more chipper for the client to not have it on codemagic, and it’s better for us to know about problems before we even start to build." => "Before we push new changes to dev branch, we must first run flutter analyze which analyzes code by linter rules.
   {list out rules in bullet form}
   After the linter is completed successfully, we run flutter tests which run all projects tests. If a test is failed, the pull request will be rejected. In the event that all tests are successful, the changes in branch will automatically be deployed on the staging environment.

Note: We moved the linter and test runs from Codemagic to GitHub actions since issues in these stages should be identified before build begins which reduces costs."
4. Please expand out more what's items under Staging Codemagic Specification mean
5. "After merging this codemagic start deploying your build automatically." -> "After merging this Codemagic will start deploying your build automatically."
6. "Release build will be uploaded to Apple Store\Google Play. Once build published all QA members receive email about new build." -> "The new release build will be uploaded to Apple Store\Google Play automatically. Once published, all QA members receive an email notification."
7. "Release Codemagic Specification" -> "Production Release Codemagic Specification" = Also, points in #4 apply here too
8. "To update some changes inside application we should rebuild and pass all steps which described before." => "Any update to application requires the new build to pass all steps."
9. "To download developer build from Slack team member should be added to QA team inside codemagic and receive Apple certificat for open application." -> "To download the developer build from Slack, the team member needs to be added to QA team inside Codemagic and receive the Apple certificate for open application."
10. "To build release application CI\CD should have installed release keys for both platforms." -> "To build a release application the CI\CD needs to have installed the release keys for both platforms."
11. "Obfuscation didn’t set up becouse it can increase app size(read more - https://docs.flutter.dev/deployment/obfuscate#obfuscating-your-app)" -> "Obfuscation isn't set up because it can increase app size(read more - https://docs.flutter.dev/deployment/obfuscate#obfuscating-your-app)"