I would like to use Debian packages to deploy software (a web application) to a Debian-based server. For reasons beyond the scope of this question we cannot use Docker (or a PaaS such as Heroku) to avoid this problem altogether.
The setup is pretty simple, we have a Git repository with some source code. We work on branches and run the code locally (no Debian-specific stuff here, in fact development is done on various & different operating systems); when we're happy we commit to a branch, wait for CI tests to run, review & merge to master.
Upon a merge to master happens we want to deploy this to a Debian server. Currently this is done "manually" via a shell script that moves files in the right place and restarts the right services. This is fragile for many reasons (the script might fail in the middle and leave the production server in an inconsistent state) and I'd like something better.
Debian packages sound like a good solution. They have built-in handling for many of the things we currently do manually via the deployment script such as copying files, (re)starting systemd services, etc. Furthermore our CI/CD system (Azure DevOps) has the concept of artifacts which are stored and can be redeployed manually at any time, so it fits well with the idea of a .deb that contains the entire application.
The problems I see:
- Debian insists on the concept of releases & versions. In our case we don't have versions and don't want them; all we care about is to be able to deploy whatever the current
masterbranch is - the.debfile itself will be copied anddpkg'd through a shell script over SSH so versioning for the purpose of maintaining an APT repository is irrelevant. - Debian insists on changelogs. We don't want to maintain those manually;
gbp dch --ignore-branch -Sgenerates one for us but it squashes all the commits into a single "change", and furthermore still doesn't solve the version problem. - The majority of the tooling & documentation assumes I have some sort of versioned source tarball and the "Debian" part of it is its own repo. Not only do I not have a concept of versions but the application's source and the Debian packaging tooling for it is in the same repo.
Questions:
- Is this a good idea to begin with?
- How do I completely ignore/work around the concept of versions and changelogs?
- Can I still preserve the install vs upgrade distinction for packages? My application has different logic for whether we're upgrading a different installation or doing a new installation from scratch (for example, on a new installation the application will depend on a configuration file that needs to be created manually, so starting the systemd service automatically is a no-go, however during an upgrade we assume the configuration file is already there so if the service is already started we do want to restart it).
