Thanks for the link. Aptly looks like a nice tool.
Your approach totally works, but we typically run into the problem of "system administrator has thing that works for them on a couple systems", then it's rather difficult to get everyone using the same tool so that people can interoperate (or bikeshedding about which one has a nifty feature and changing tools every six months) -- or worse, breaking something because they didn't understand how the other tool's process was different.
If different teams want to build their own packages (using whatever toolchain they want, which results in a .deb) and have them hosted on the company repo server(s) - why should they care how the hosting works? Have them supply (usually an upload of some kind) the built (and if necessary, signed) package files, and their job is done.
I know it's hip and cool to treat "devops" as meaning "developers get their hands dirty with ops and we have no separation" but that's a ridiculous interpretation of the concept.
There is a definite and identifiable skillset involved in system and network administration (aka Ops, Infrastructure, or historically "IT department").
There is no reason developers can't learn these skills (I actually went the other way, studied Network Engineering, learnt dev later, now I do both) but it's stupid to assume that just because a developer can install vagrant, that he or she is qualified to run or make key decisions about core infrastructure and services.
See my other comment, but hosting's the easy part, managing packages from "packaged, this afternoon, works on dev's machine" to "tested and works for a couple thousand people, let's deploy this" is the challenge. The bad ways of doing this involve every team setting up their own repos (differently! ha!) to test things before pushing them up a level. This happens a lot, absent defined structure. So does things like e-mailing packages around, two people bumping a version number to the same thing, and so on.
I completely agree that developers shouldn't be making ops decisions and have scars to prove it.
In an ideal world, we'd only be getting packages built on integration test passes, and automatically pushed from CI. I've got that for some cases, but it's still a manual push process for others.
Why do you run into that situation? Do your developers not have access to your interal repo? Emailing packages around sounds like a symptom of a process problem.
The way I use dpkg-scanpackages is to have a single, central repo machine, with independent repositories for different projects. Publishing a .deb is the same for any project - scp, then ssh and run make in that project's directory. I have a very short shell script called publish-deb which does exactly that.
It could be that I've just not bumped into problems which require them, but I've not found a project which offered features above the set this gives you where the trade-off is worth the complexity. "Everything works this very simple way, there's almost nothing to learn" is very persuasive.
Comments
Thanks for the link. Aptly looks like a nice tool.
Your approach totally works, but we typically run into the problem of "system administrator has thing that works for them on a couple systems", then it's rather difficult to get everyone using the same tool so that people can interoperate (or bikeshedding about which one has a nifty feature and changing tools every six months) -- or worse, breaking something because they didn't understand how the other tool's process was different.
Aptly is about hosting packages only right?
If different teams want to build their own packages (using whatever toolchain they want, which results in a .deb) and have them hosted on the company repo server(s) - why should they care how the hosting works? Have them supply (usually an upload of some kind) the built (and if necessary, signed) package files, and their job is done.
I know it's hip and cool to treat "devops" as meaning "developers get their hands dirty with ops and we have no separation" but that's a ridiculous interpretation of the concept.
There is a definite and identifiable skillset involved in system and network administration (aka Ops, Infrastructure, or historically "IT department").
There is no reason developers can't learn these skills (I actually went the other way, studied Network Engineering, learnt dev later, now I do both) but it's stupid to assume that just because a developer can install vagrant, that he or she is qualified to run or make key decisions about core infrastructure and services.
See my other comment, but hosting's the easy part, managing packages from "packaged, this afternoon, works on dev's machine" to "tested and works for a couple thousand people, let's deploy this" is the challenge. The bad ways of doing this involve every team setting up their own repos (differently! ha!) to test things before pushing them up a level. This happens a lot, absent defined structure. So does things like e-mailing packages around, two people bumping a version number to the same thing, and so on.
I completely agree that developers shouldn't be making ops decisions and have scars to prove it.
Right yes I understand now, and agree.
I wasn't saying the existing systems are foolproof, but I don't think PPA's add anything to help the problem you're describing.
Ah and I just realise you were originally replying to the bit about "dpkg-scanpackages and a Makefile”!
In an ideal world, we'd only be getting packages built on integration test passes, and automatically pushed from CI. I've got that for some cases, but it's still a manual push process for others.
Why do you run into that situation? Do your developers not have access to your interal repo? Emailing packages around sounds like a symptom of a process problem.
The way I use dpkg-scanpackages is to have a single, central repo machine, with independent repositories for different projects. Publishing a .deb is the same for any project - scp, then ssh and run make in that project's directory. I have a very short shell script called publish-deb which does exactly that.
It could be that I've just not bumped into problems which require them, but I've not found a project which offered features above the set this gives you where the trade-off is worth the complexity. "Everything works this very simple way, there's almost nothing to learn" is very persuasive.