Fastlane実戦(五):高級用法

6813 ワード

前の4つの文章の基礎知識と異なるシーンの紹介を経て、みんなはすでにFastlaneに対して1つの比較的に完全な認識があることを信じて、同様に、今日私はやはりいくつかの実際のシーンを結びつけて、Fastlaneのいくつかの高級な使い方を話します.
前言
ソフトウェア開発は芸術品を完成させるように、順序を追って漸進的に、絶えず磨く過程である.最初は、ある言語やフレームワークを十分に理解していなかったため、機能を実現する段階にとどまり、より良い特性とより効率的な方法で問題を解決できるかどうかをあまり考慮することはありませんでした.
プログラミングの経験の蓄積と言語の枠組みに対する理解に従って、前に書いた多くのコードは実は多くの問題が存在していることを発見して、すべて多くの最適化と向上の空間があって、そこで責任感とプログラミングに対する愛のため、私达はきっと時間をかけて絶えずコードを再構築して優化して、自分が満足するまで.
Fastlaneを使う過程も同様で、初めてこのような新しいツールを発見した時、心の中で何だか興奮して、そこで三七二十一にかかわらず、すぐに手を出して使って、それから使うシーンが増えるにつれて、問題も次第に明らかになって、そこで私たちはFastlaneのいくつかの高級な使い方を探して、もっと効率的で、もっと優雅に問題を解決します.
前置および後置アクション
一般的に、iOSの自動化プロセスを処理する際には、ユニットテスト、ライブラリコンパイルリリース、APPパッケージなど、さまざまなシーンに直面しますが、APPパッケージでは、Test、Adhoc、AppStoreなど、さまざまな環境を区別する必要があります.これらのシーンと環境の処理方法は異なるので、それぞれの状況に対して、対応するLaneを作成する必要があります.例えばiosという名前のfastfileのファイルです.内容は次のとおりです.
#      Lane
lane :test do |options|
  git_pull
  cocoapods
  xctest
end

# AdHoc     Lane
lane :adhoc do |options|
  git_pull
  cocoapods
  increment_build_number
  gym
  upload_to_fir
end

# AppStore     Lane
lane :appstore do |options|
  git_pull
  cocoapods
  increment_build_number
  gym
  deliver
end

もちろん、以上のLaneはすべて簡潔で、ただのヒントで、実際の状況は複雑になります.これらのLaneでは、各プロセスには事前の条件があることがわかります.
  • git pull最新コード
  • 最新のcocoapods依存
  • を更新
    だから、ルビーon Railsのcontrollerのフロントフィルタのようなメカニズムがあって、この状況を便利に処理できるかどうかを聞くに違いない.答えは肯定的で、このように、1つのFastfileの中で、各Laneが共有する前置フローの場合、Fastlaneが提供するbefore_を借りることができます.allメソッドで処理し、ios_fastfileでは、次のコードを追加します.
    before_all do |lane, options|
      git_pull
      cocoapods
    end
    

    before_allはその名の通り、各メソッドを実行する前に最初に実行されるコードであり、before_を使用する.オールios_fastfileのコードは、次のように簡略化できます.
    before_all do |lane, options|
      git_pull
      cocoapods
    end
    
    #      Lane
    lane :test do |options|
      xctest
    end
    
    # AdHoc     Lane
    lane :adhoc do |options|
      increment_build_number
      gym
      upload_to_fir
    end
    
    # AppStore     Lane
    lane :appstore do |options|
      increment_build_number
      gym
      deliver
    end
    

    ええ、コードが簡略化されているように見えます.そして、後で共通の前置きコードを追加するには、before_に置くことができます.allで処理し、メンテナンスが非常に便利です.
    また、Lane自体や使用しているOptionsパラメータもbefore_に簡単に渡すことができます.allメソッドは、git_を処理していないLaneがあるなど、さまざまな特殊な状況をより便利に処理することができます.pullの流れは,メソッドに判断を加えるだけでよい.
    もちろんbefore以外はFastlaneにはafterも用意されていますallは共通の後置論理を処理します.例えば、私たちはすべてのlaneの後、SlackやHipchatを通じて関連するエンジニアたちに通知すると、これらのactionをafter_に書くことができます.allメソッドで.
    after_all do |lane,options|
        slack(message: "fastlane was successful", success: true)
    end
    

    各Laneの実行中にエラーが発生した場合は、SlackやHipchatなどのツールでお知らせする必要があります.この場合、Fastfileにグローバルなerrorメソッドを追加できます.
    error do |lane, exception|
      slack(message: exception.message, success: false)
    end
    

    リファレンスメカニズム
    新しいテクノロジーがチーム内に導入されると、プライマリビジネス以外のプロジェクトからグレースケールの試みが行われることが多い.私たちも例外ではありませんので、まずFastlaneを私たちの医師版iOSクライアントに導入し、しばらく使い心地がよかった後、Androidプラットフォームとユーザー版クライアントに普及し、最後に様々なプライベートライブラリプロジェクトの管理に導入しました.現在、約30以上のプロジェクトに関連しています.この過程で、2つの問題を発見しました.
  • 多くのactionをカスタマイズしているため、これらのactionは各プロジェクトのfastlaneディレクトリにコピーする必要があります.これにより、任意のカスタムactionを追加または変更するには、各プロジェクトで処理する必要があるというメンテナンスの問題が発生します.
  • 現在のプロジェクトはタイプ別に4種類に分けられています.iOS App、iOS Podライブラリ、Android App、Android AARライブラリです.同じプロジェクトタイプに対してlaneの処理フローは基本的に同じなので、同じタイプのプロジェクトごとにFastfileが基本的に一致しています.これは1と同じ問題をもたらしました.いずれかのプロジェクトのFastfileを修正する場合、つまり、これらのFastfileは、それぞれのプロジェクトディレクトリの下にあるfastlaneフォルダに格納されているため、他の同じタイプのプロジェクトのFastfileも変更する必要があります.

  • 最初はプロジェクトが少なかったとき、手作業で処理することができて、プロジェクトがだんだん増えてきたとき、問題はますます深刻になって、直すところが多いだけでなく、間違いも起こりやすいので、私たちは1種の引用のメカニズムが存在するかどうかを考えて、最上階で1部の共通のactionとfastfileを保護することができます.これにより、プロジェクトにこれらの最上位レベルのファイルを導入するだけで、上記の問題を解決することができます.
    Fastlaneの特性をよく研究した結果,この問題は著者の考えの中にあることが分かった.Fastlaneは、リファレンスメカニズムimportだけでなく、リモートリファレンスモード、すなわちimport_を提供します.from_git.
    このメカニズムがあれば、カスタムactionたちとFastfileたちを統一的に管理するだけでなく、git上に置いてリモート分散管理を行うこともできます.これにより、各プロジェクトは自分のFastfileの上部で参照声明を行うだけでいいというメリットがあります.
    #   Git  :
    import_from_git(url: 'https://github.com/GengmeiRD/Fastfiles', branch: 'master')
    
    lane :appstore do |options|
      # ...
    end
    

    このようにfastlaneのコマンドを実行するたびに、gitから必要なファイルcloneというプロジェクトをローカルの一時フォルダに最初に実行し、その後、関連コマンドを実行します.もちろん、あるプロジェクトでリモートのlaneを使用したくないのではなく、カスタマイズする必要がある場合は、プロジェクトのFastfileにこのlaneを書き直すだけです.
    #   Git  :
    import_from_git(url: 'https://github.com/thierryxing/Fastfiles', branch: 'master')
    
    #        lane
    lane :do_deliver_app do |options|
      # ...
    end
    

    もちろん、これらのactionとfastfileをリモートで管理するのが面倒だと思ったら、同じようにローカルリファレンスを使用して管理することができます.fastlaneは、ローカルのFastfileとactionディレクトリを導入するための2つのコマンドを提供しています.
    import "../GeneralFastfile"
    actions_path '../custom_actions_folder/'
    
    lane :appstore do |options|
      # ...
    end
    

    チーム内で使用しているリモートアクションとFastfile管理はgithubに公開されています.興味のある方は参考にしてください.https://github.com/thierryxing/Fastfiles
    コンテキスト定数
    Fastlaneを使用する過程で、AppStoreのアカウントとパスワード、ipaとdsymファイルの出力アドレス、シミュレータやデバイスのUDIDなど、コンテキストに関連する定数が必要になることが多い.これらの定数はFastfileで直接書くとメンテナンスに不利であることは明らかである.次のような方法で処理することができます.
    dotenvの使用
    まずgemを使用してdotenvをインストールし、次に.envファイルを追加し、次に使用する定数を定義します.たとえば、次のようにします.
    WORKSPACE=YourApp.xcworkspace
    ITUNESCONNECT_ACCOUNT=your-itunesconnect-account
    

    次にfastfileでENVを使用して呼び出します.
    lane :appstore do |options|
      increment_build_number
      gym(workspace: ENV['WORKSPACE'])
      deliver(username: ENV['ITUNESCONNECT_ACCOUNT'],)
    end
    

    最後にこの.envファイルをFastfileと同じクラスのディレクトリにコピーすればいいです.もちろん、複数のプロジェクトで共通の定数が必要な場合(iTunesConnectのアカウントなど)は、同じ.envファイルを指すソフト接続を確立し、ディレクトリに.env.defaultファイルを作成し、本プロジェクトの下にある固有の定数を配置することができます.
    exportコマンドの使用
    Macまたはlinuxオペレーティングシステムを使用している場合は、システム環境の変数でexportコマンドを使用してシステムレベルの定数を直接定義できます.もちろん、他の定数と競合しないようにFASTLANE接頭辞を追加することをお勧めします.たとえば、次のようにします.
    #set env vars
    export FASTLANE_WORKSPACE=""
    export FASTLANE_ITUNESCONNECT_ACCOUNT=""
    

    呼び出し方法は.envを使用するのと同じです.
    lane :appstore do |options|
      increment_build_number
      gym(workspace: ENV['FASTLANE_WORKSPACE'])
      deliver(username: ENV['FASTLANE_ITUNESCONNECT_ACCOUNT'],)
    end
    

    締めくくり
    以上のいくつかの高度な使い方は筆者が使用中に出会った隅にすぎず、より多くのサプライズはみんなが自分で探求して発見することを待っています.公式ドキュメントには全面的な紹介があります.https://docs.fastlane.tools/advanced/
    Fastlaneは継続的なメンテナンス、急速な発展のツールであり、筆者の最初の文章から現在まで、わずか2ヶ月の間に、Fastlaneはすでに20以上のバージョンを発表し、Githubに2000以上のstarを追加し、同時に100人以上のエンジニアがContributorsの大家族に参加した.事実は再び優秀なオープンソースプロジェクトがいつもみんなの認可を得て、関心と参加を得ることができることを証明します.
    本文はFastlane実戦シリーズの第5編の文章も最後の文章で、このシリーズの文章が本当にFastlaneを理解するのに役立つことを望んで、このシリーズの文章を見終わった後に、もっと多くの学生がFastlaneと各種の自動化ツールを借りて自分の効率を高めることを望んで、結局重複的な労働とプロセス化の仕事は機械たちに任せましょう.
    最後にFastlaneを使って楽しんでください.