We’re excited to announce the release of Targeted Deploy, a major enhancement to the deployment process in Appfarm Create. This feature is available now for customers on the Essential tier and above.
What is Targeted Deploy?
Targeted Deploy enables you to deploy specific apps, services, themes, and schedules to any environment—without waiting for other in-progress work. This gives you unprecedented control over what gets deployed and when, streamlining your development workflow and making it easier to ship changes faster.
With Targeted Deploy, you choose exactly what you want to deploy. Need to push just that one app you’ve been working on? No problem. Want to deploy directly to Production? You can do that too.
Work independently within the same Solution
No more coordinating deploys with your team. Each developer can work on and deploy their changes without affecting others’ work in progress. This means faster development cycles and fewer “is it OK to deploy?” messages.
Smarter dependency handling
Appfarm automatically identifies and includes any dependencies your selected components need. If your app requires data model changes, they’ll be bundled in automatically.
How it works
When you click the Deploy button, you’ll now see additional options:
Choose between “All changes from [Environment]” or “Selected changes from [Environment]”
If selecting specific changes, check the apps, services, themes, and schedules you want to deploy
Choose your target environment (Test, Staging, or Production)
Deploy instantly or schedule for later
Appfarm automatically checks for dependencies to ensure everything needed for your selected changes is included in the deployment.
Getting started
Targeted Deploy is available now for all customers on the Essential tier and above. Simply click the Deploy button in Appfarm Create to see the new options.
Check out the documentation for more details on how to use this feature.
We’d love to hear about your experience with Targeted Deploy. How is it going to change your deployment workflow? Please share your thoughts and feedback in the comments below!
Could you clarify what causes the reload dialog in Appfarm?
Our expectation was that if an app is not selected in the “Selected Changes” section during a deployment, it would remain unaffected. However, we were surprised to see a reload dialog appear in an app that wasn’t included in the deployment selection.
Is this behavior due to shared dependencies between apps? If so, how can we determine in advance which apps will actually be impacted by a deployment?
Additionally, are there scenarios where deploying a service could trigger a reload dialog for an app?
One of the core benefits we expected from this feature was the ability to perform less invasive deployments. Gaining a clearer understanding of these triggers would help us better manage our release process.
By default, apps that are not selected in “Selected Changes” should be unaffected by deploy, as you say. However, you are right that shared dependencies might cause other apps to reload—for instance, changes to object classes that are used in multiple apps or services.
We noticed some cases during testing where apps were reloaded on deploy when they shouldn’t have been. So if you have specific cases with unexpected behaviour, please provide us with the details, and we can look into if there are any bugs.
For now, we do not have reference checking on dependencies in the deploy dialog, so you would have to use the reference finder on the side for each dependency to figure out which other apps will be affected.
I will register a challenge internally to improve the reference checking of dependencies and visualisation of how different apps and services will be affected by deploy.
Any chance this will be even more fine grained in the future? We are for example 3 devs working on the same app, but with different views, actions and data sources. It would be really cool to be able to select which views, actions and data sources and/or one person’s changes, leaving the other ones as is. It could even be the “diff” page we see today, but to easily be able to remove changes not wanted deployed from there, or oppositely, select those we want deployed.
Yes, that is definitely on our minds! There are some other aspects we want to improve first so there is no definite timeline yet, but increased granularity in deployment is something we want to provide further down the road.
