fastlane automatic packaging project using the Package (Enterprise package / testing package) multi-service extension targets

Explanation

Fastlane specific installation here I do not say a large online documentation about the idea of using only record when it came to the scene and solutions
official document:Fastlane Docs

Scenes

Our projects are generally sub-package enterprise and non-enterprise package a (Certificate) is responsible for the distribution of a given device installation testing

Generally, there are two common treatments:
A, add different multi-targets to distinguish between business and development kit bag and certificate identifier or some configuration items to select a target can be packaged as shown in the package:

Multiple target

Packaging can be used in this way fastlane reference Fastlane multi Target automation packaged and released this article

B, the project maintains only one main target at the same time added some Service Extension (pictured above add a widget, watch, notification, etc. extension)
when using fastlane packages we take into account the bundle identifier and sign certificate enterprise package and non-enterprise package is not the same we do not intend to branch warehouses or re-added to the project targets a distinguished enterprise package (such as a)
so think of ways to change the script bundle id and sign cer replaced by corporate package includes some configuration change target extension configuration so a project can be achieved are playing a key enterprise and non-enterprise package package test With that in mind checked again and found to be the official document of instructions automatic_code_signing

Key	Description	Default
path	Path to your Xcode project	*
use_automatic_signing	Defines if project should use automatic signing	false
team_id	Team ID, is used when upgrading project
targets	Specify targets you want to toggle the signing mech. (default to all targets)
code_sign_identity	Code signing identity type (iPhone Developer, iPhone Distribution)
profile_name	Provisioning profile name to use for code signing
profile_uuid	Provisioning profile UUID to use for code signing
bundle_identifier	Application Product Bundle Identifier

But found that did not seem to meet the needs of each of our targets extension of the bundle identifier is independent
so we've tested to find this method update_app_identifier

Code Example

Update an app identifier by either setting CFBundleIdentifier or PRODUCT_BUNDLE_IDENTIFIER, depending on which is already in use.

update_app_identifier(
  xcodeproj: "Example.xcodeproj", # Optional path to xcodeproj, will use the first .xcodeproj if not set
  plist_path: "Example/Info.plist", # Path to info plist file, relative to xcodeproj
  app_identifier: "com.test.example" # The App Identifier
)

Handle multiple target extension

platform :ios do
   desc "打包企业版 更改项目和扩展bundle id"
   lane :test do
      update_app_identifier(
          xcodeproj: "testApp.xcodeproj",
          app_identifier: "com.testApp.testAppPublic",
          plist_path: "testApp/Supporting\ Files/Info.plist",
     )
     update_app_identifier(
          app_identifier: "com.testApp.testAppPublic.Extension",
          plist_path: "testAppExtension/Supporting\ Files/Info.plist",
     )
            .........
     automatic_code_signing(
       use_automatic_signing: true,
       team_id: "xxxxxxx",
     )

Actually implements a lane script functions of each Extension is configured to perform once update_app_identifierto update the bundle identifier and plist_path
course, you can also write your own script to change configuration items .xcodeproj to do more changes

Reproduced in: https: //www.jianshu.com/p/6a9a5b6f70a0