Beneath the code: SUSE Enterprise Linux construction mechanics
As every good developer knows, when you want to learn more about what a platform or tools provider is bringing through the release pipeline: ignore the news, delete the press releases, don’t look at the advertisements… read the coder blogs instead.
Microsoft’s MSDN has adopted this approach for most of the last decade and it is – very arguably – where the real meat (or plant-based protein substitutes with soya-enrichment) is.
Also well versed in this practice is German open source operating system softwarehaus SUSE.
The company’s Vincent Moutoussamy has this month posted what comprises his fifth blog of a series that provides insight into SUSE works to deliver its Linux Enterprise product development.
The complete discussion is linked on Vincent’s name above, but here’s a snapshot.
Overall, Moutoussamy refers to what he calls the ‘increasing pace of open source project engineering’ as the team works to build new requirements as driven by SUSE’s customers, partners and ‘business-related constraints’, the latter being a very open admission to the commercial edge.
Point out the different types of Linux distributions you can find in the wild, Moutoussamy says that now is a good time to know more about what each distribution brings and what SUSE Linux Enterprise (SLE) offers.
The difference in release cadence often makes all the difference. Some distros are released as soon as possible on a CI/CD basis (such as openSUSE Tumbleweed, ArchLinux, Manjaro, Gentoo) and some are more formally scheduled for release once to twice a year so that updates are rolled out across the entire stack (such as in Ubuntu, Fedora, Debian).
Still others have a slow cadence (roughly yearly) and the examples there would be openSUSE Leap, Ubuntu LTS, SUSE Linux Enterprise Server, SUSE Linux Enterprise Desktop, RHEL, CentOS.
Moutoussamy goes on to talk about the Factory Project, the development code stream all SUSE distributions are based on, which is not in fact a Linux distribution!
“It is the immediate source for openSUSE Tumbleweed and it eventually ends up in openSUSE Leap and the SUSE Linux Enterprise distributions. Put it simply, Factory is the development repository for openSUSE and SUSE in a CI/CD fashion. Now you might wonder what’s the deal with the Factory and openSUSE Tumbleweed relationship,” poses Moutoussamy.
He says that Factory is getting a constant flow of codes without any proper Quality Assurance apart from various code reviews (mostly done by bots), so the openSUSE community creates snapshots of Factory tested with openQA.
“When a snapshot is good, it becomes an update for openSUSE Tumbleweed; hence a rolling release,” he added.
Smooth migration path
Looking at real world use cases, Moutoussamy insists that SUSE wants a smoother migration path between SLE and openSUSE Leap, while it also looks for more direct collaboration with the openSUSE community.
He says that – in answer to this – SUSE is making easier for the community to contribute directly to openSUSE and SLE via new dedicated channels. So the community is still able to shape and submit changes to the next distribution version with this new setup.
“The ultimate goal on a project perspective is to make an healthy and self-sufficient ecosystem, and on a distribution level to have a good balance between an environment suitable for production and for innovation,” said Moutoussamy.
Sharing more than code
Last but not least, Moutoussamy talks about the openSUSE community and how SUSE wants to share more than just code.
“So next we will talk about some of the underlying processes glueing everything together but also about the great tool we are using: Open Build Service (build) and openQA (test),” he concludes.
Can we imagine that one day, all technology vendors will talk about the way they actually build code and perform rollout cadence and express the need to balance open source community and commercial requirements in a product that still, ultimately, progresses forward year-on-year? We can dream, surely.