I’ve been doing quite a bit of research on this but still couldn’t figure out the best way to approach package deployment.
To better paint a picture imagine a robotics company with 3 software engineers that need to supply robots with their packages that can’t be open sourced. Let’s assume we deal with around 30 packages.
The first thing I looked at was the buildfarm tutorials, however spinning up 3 Amazon instances sounds like an overkill for such a low amount of packages, especially given the small amount of developers.
What is your experience with these things? So far, apart from buildfarm repos, I’ve come across ros_bundling, aws_robomaker.
Does anyone have tips on what I could explore? I’m ideally looking at the least friction method that won’t require too much maintenance. Any tips/repos/tutorials would be highly appreciated!
Hi,
Have you considered snaps? They are an easy way to distribute self-contained applications, including ROS 1/2 stacks. As an example, find here a short blog post series on creating a Snap for the TurtleBot3.
Years ago I looked into making apt/.deb packages with bloom and hosting them via IIRC aptly. Never fully made it to production use for various non-technical reasons.
Deb packages using Bloom are certainly one way to go. Bloom can generate them automatically from any ROS package. And you don’t have to upload them anywhere, they’re just built locally on your machine. Then you can decide if you want to spin up a local APT repo or just distribute the packages via rsync or similar ways. We did this (with the custom APT repo) with one package that was difficult to build so that developers have easier lives…
You could also store the contents of your workspace’s install directory on some network location and just rsync all of its contents to the robots. That would also work (assuming you have a way of installing additional dependencies, i.e. calling rosdep install after rsync).
What works quite well for us is to build debs using just cmake/cpack and upload them to aptly repos (mostly a release and a testing repo).
So essentially for all our packages (most of them ROS independent packages/libs) we just run make package, upload them to the aptly repo (from CI) and then have a “simple text file” with exact versions of these debs (that basically form a “distribution”) that we install to the devices/robots (or bake into an installable image).
Obviously there is some convenience tooling around it, but that’s basically it…
@Jeremie I’ve looked breifly into Snap around 3 years ago. Back then I remember having some issues with sandboxing, especially around device access. I think it might be worth taking another look at it.
@Loy@peci1 thanks for the recommendation! I’ve just checked bloom and it seems quite easy to create a .deb assuming I can resolve the dependencies. I will definitely give this approach a shot first.
@flixr thanks for sharing your approach! I’ll give this a shot once I figure the optimal workflow with debs and aptly. I certainly like the idea of setting this up once for every package and not having to think too much about it.
