🚧 Note this is still a work in progress, and is not ready for production yet 🚧
Creating a new release for an Objective-C/Swift open source framework is a tedious process. This fastlane setup is an attempt to streamline that process by creating a single button to generate a new release, allowing developers to focus on great updates, without the overhead of creating new releases.
It is recommended to have a high level understanding of what fastlane is, but it is not required. You can read up more on fastlane here.
To install fastlane, simply use gem (related: Should I use sudo?):
[sudo] gem install fastlane
The goal is to create a one button release like so with almost no overhead for a developer.
fastlane prepare_framework_release version:3.0.0 env --deploy
That does the following:
- Verifies the git branch is clean
- Ensures the lane is running on the master branch
- Verifies the Github milestone is ready for release (no open issues, and at least one closed issue)
- Pulls the remote to verify the latest the branch is up to date
- Updates the version of the info plist used by the framework
- Updates the version of the podspec
- Generates a changelog based on the Github milestone
- Updates the changelog file
- Commits the changes to master
- Pushes the commited branch to the remote
- Creates a new tag
- Pushes the tag to the remote
- Runs the tests on the CI server
When the tests have passed on CI, the complete_framework_release lane will automatically run:
- Generates a changelog for the Github Release Page
- Creates a Github Release
- Builds Carthage Frameworks
- Uploads Carthage Framework to Github Release
- Pushes podspec to pod trunk
- Lints the pod spec to ensure it is valid
- Closes the associated Github milestone
In order to get the most out of this tool, it is recommended you manage your Github repo with the following best practices. It's easy to do, and gives you a lot of automation power with fastlane. Below is how AFNetworking is being managed:
- Any changes that should be referenced in the changelog shoud be merged using pull requests.
- The title of the pull request should be concise, and ready to display in the changelog. This means as the admin of the repo, it may be appropriate for you to edit a pull request's title to make it more meaningful.
- All releases should be managed with a Github milestone. Not only does this provide a well documented place for users to get a clear view of what went in to a release, but it will also serve as the main component for changelog generation. The milestone name should match the planned tag name.
- All issues merged should be grouped into one of five categories using Github labels. This allows the changelog to be divided into multiple, logical sections, like so. You can see an example of an AFNetworking release managed this way.
- Added
- Updated
- Changed
- Fixed
- Removed
There are primary use cases for these fastlanes: testing and deployment. When used together, a full continuous integration system can be created.
Getting the testing harness configured is an easy process.
- Configure the scheme's test action to run a test target, and confirm all tests pass locally
- Setup the Fastfile
- Setup the env files
- Setup CI (optional)
- Profit 💰
Follow the getting started guide to configure the framework for testing.
Getting up and running is a simple process:
- Setup the Fastfile
- Setup the env files
- Setup CI (optional)
- Generate a Github API Token
- Generate a Pod Trunk Access Token
- Profit 💰
A full deployment guide has been created to help get developers get started with automating deployment.
The lanes provided are divided into two groups: lanes meant for for testing, and lanes meant for deployment. In combination with the Github best practices above, developers can fully automate the release process.