Snap crafting

Snapcraft is the developer tool available for creating, building, releasing and updating snaps on any Linux workstation. Comprehensive training workshops are offered for engineering teams to quickly become comfortable with creating and publishing snaps.

Snaps are built in 3 simple steps:

  1. Model
    Identify the software modules, libraries and dependencies that make up your application in a yaml file.

  2. Build
    Use the Snapcraft build tool to package your application in a snap in a virtual machine on your host computer.

  3. Publish
    Publish your snap to the public (snap store) or private repository for snaps (IoT app store). See the next section for more information about publishing snaps.

Maintaining snaps

Snapcraft integrates with CI/CD tools to build and release apps automatically upon software commits. Snaps use the concept of channels for software versioning. Channels define which release of a snap is installed and tracked for updates.

Channels consist of tracks, risk-levels and branches. When released, snaps are published to a track in the public or private repository they are hosted in. There are fours risk-levels in each track, each reflects a level of software maturity:

  • stable: production-ready
  • candidate: for testing purposes prior to production deployment
  • beta: for testing of the latest development features
  • edge: closely tracks development, often auto built and released

Branches are optional and hold temporary releases intended to help with bug-fixing. Channels provide a consistent method of software versioning, standardising software delivery for developers and users.

​​Helpful resources

The “Snaps in Ubuntu Core” link references a webpage which no longer exists. It looks like it’s been renamed to https://ubuntu.com/core/docs/snaps-in-ubuntu-core

1 Like

The “training workshops” link is broken.

Number of points.

First, the opening sentence seems redundant. What is the difference between creating and building a snap?

Typo: “fours”.

Finally, I don’t think “risk-levels” should be hyphenated.

One more point – I would rename point 1. from “Model” to “Design”, as we already have an established use for the word “model”.