Nevercode workflows is an advanced feature that allows you to set up a number of different configurations for your project. This is useful if you want to maintain separate development, staging and master configurations of your app, for example, without having to manually change the settings before every build. Each workflow describes how your project is to be built, tested and published by Nevercode, allowing you to fully automate your CI process.
This guide covers the following topics:
You can add one or more new workflows to easily maintain and build different configurations of your app. The first new workflow will be created with the exact same configuration that you have already set up for your app.
To add a new workflow:
- Navigate to the Workflows section in your project's settings.
- Click Add new workflow. A copy of your initial workflow is generated that you can rename and customize as you wish. All your environment variables and scripts, build settings and signing files will be duplicated into the new workflow. You can also rename your original workflow which is now listed as Default workflow.
Once you have more than one workflow, you can create new ones by duplicating any of the existing workflows. Click on the menu icon to the right of the workflow for options:
- Change settings — configure workflow settings
- View builds — open the build overview for that workflow
- Change name — edit the name of the workflow
- Duplicate workflow — make a copy of the workflow
- Delete workflow — delete the workflow along with its build history and artefacts
Note that all your workflows will appear in the left menu one after another and can be expanded or collapsed for easy configuration.
When you now open the build overview on Nevercode, each workflow is displayed on a separate tab. You can switch between the tabs to see the builds for that workflow's main branch as well as any feature branches, pull requests or tags tracked by the workflow.
In this section, we'll pinpoint some of the most important configuration aspects for your possible workflows.
Note that while your workflows started out as duplicates, they become separate entities once created. Any changes made to one workflow won't affect any of the others. It is advisable to go over the settings of your new workflows to make sure that everything is configured as required.
Instead of targeting all the branches in your project, you can select only the relevant ones.
- Navigate to the Build section of the workflow that you're configuring.
- Select one branch as the main branch in the Main branch field.
- Create a branch pattern that will match the name of the main branch as well as any feature branches (if available) that you want to track. Branches matching the pattern will be immediately highlighted.
- Click Add branch pattern to save the branch setting for this workflow.
If there are tests present in your project, Nevercode will by default run them during the build. However, you can enable or disable a particular test type for a workflow.
- Navigate to the Test section in your workflow settings.
- Tick or untick the box for Enabled for the tests that you want Nevercode to run or skip during the build process.
- Save the configuration by clicking Save.
For more information on testing a particular type of app, see the page on supported test frameworks.
For each workflow, you can set up different notification methods to get notified when a build fails or its status changes. This can be done in the Notifications section of the workflow. You can find more details about supported notification methods in our documentation.
Enable automatic distribution of successful builds by setting up the publishing channels that suit the needs of the workflow. You may want to publish the build artefacts internally to your team or distribute them publicly. Publishing options can be configured in the Publishing section of the workflow.
Similarly to other settings, the code signing settings and signing files will be copied when you create a new workflow. However, signing will be handled separately for each workflow from there on and can be configured in the Code signing section of the workflow. See our documentation on Android signing and iOS signing for information on app signing.
If you have set up Git hooks, your project will be built every time you push changes to your repository. By default, automatic building is disabled. You may want to keep this feature disabled for your master branch and trigger building manually, but enable it for your development or staging workflow. Automatic building can be enabled in the Build section of your app settings.
This section outlines a few good scenarios for setting up development, staging and master workflows after you have successfully added a project to Nevercode.
To set up a development workflow:
- In the workflow's Build section, select your development branch as the main branch for this workflow. Consider enabling automatic builds. Then, type and add the branch pattern for the branches you are going to track for this workflow. You'll want to track the development branch as well as any feature branches that target it and will ultimately turn into PRs, but exclude your master and staging branches.
- In the Test section, enable Nevercode testing.
- Then, in the Notifications section, configure the desired notification options, say Slack, to get notified when the build fails.
- To share the builds with your development team, navigate to the Publishing section and set up the appropriate publishing methods. You may also wish to consider enabling publishing for pull request builds so that PR binaries can be tested by your team before getting merged into development.
To set up a staging workflow:
- In the workflow's Build section, select your staging branch as the main branch for this workflow. You may want to enable automatic building. The staging workflow is only going to track a single branch, so type and save the branch pattern to match your staging branch.
- In the Test section, enable Nevercode testing.
- Since you want staging builds to be distributed to your QA team, navigate to the Publishing section and enable the publishing channel(s) you'd like to use for this purpose. Additionally, if some of your app's users participate in the beta testing process, you can set up publishing to the Google Play store's Internal, Alpha or Beta tracks.
- Keep in mind that the Play store only accepts signed binaries, so make sure to set up signing in the Code signing section of the workflow. See also our documentation on Android signing and iOS signing.
To set up a master workflow:
- In the workflow's Build section, select your master branch as the main branch for this workflow. Also, change the branch pattern to track only that branch.
- Still in the Build section, you may want to check that automatic builds for this workflow are disabled — this is the version of your app that will be sent to the app store and you may prefer to initiate this step manually rather than in response to events in your code repository.
- Set up signing in the Code signing section of the workflow to enable installing your app on real devices. See also our documentation on Android signing and iOS signing.
- In the Test section, consider enabling testing to catch bugs before you release your app publicly.
- Finally, in the Publishing section, configure the publishing channels that will announce to your whole team that a new version of your app is being released to the public. In addition, enable publishing to the Google Play store's Production track.
Updated about a month ago