You can use systemd presets to affect whether a systemd service will default to being enabled or disabled at installation time.
The Debian presets default to enabling all services as they're installed, so you only need to ship a preset to the development workstations (the default behavior matches what you want to happen in production), by shipping a file such as
/etc/systemd/system-preset/80-foo.preset containing a line that says
If you manage your developer workstations using a system such as Puppet, Chef, Ansible, etc., you can use them to ship such a systemd preset configuration, that should make it easy for you to apply the policy to developer workstations only and not production machines.
Your .deb package should use the
systemctl preset command to enable the service, since that command will respect the preset configuration.
As @JdeBP and @sourcejedi point out, the Debian macros in deb-helpers (such as
dh_systemd_enable) do that already, they invoke
deb-systemd-helper which will use
systemctl preset by default (with a small caveat that if you remove (but do not purge) the package, and later re-install it, it will then not enable the service, even if you remove the preset file.) See this comment in
# We use 'systemctl preset' on the initial installation only.
# On upgrade, we manually add the missing symlinks only if the
# service already has some links installed. Using 'systemctl
# preset' allows administrators and downstreams to alter the
# enable policy using systemd-native tools.
For more information on the systemd feature of presets, see the man page of systemd presets and of the command
systemctl preset which implements it.