A bag o' tricks from the Perlmeister
Infrastructure as Code
To make sure that code does not only work in the development environment, but also for the users in their worlds, the release process must ensure two things. The generated artifact is exclusively allowed to pick up the source code from the Git repository and is not allowed to rely on local files; this means that the build can always be reproduced. And, before the product is launched into the wild, it has to pass through the accompanying test suite, which simulates the end user's view.
Professional developers use build servers for this. They automatically wake up with tools like Jenkins or similar, if new sources appear in the Git repository. They grab the new code, start the build, run the tests, and put together an artifact such as a tarball or an RPM package if successful. They then upload the latter to the distribution server in one fell swoop. Open source projects often use Travis-CI [3] for this. It's an excellent build hosting provider that sets up a build server for a GitHub project at the push of a button and is happy with simple three-liner configurations that live alongside in the source code.
A virtual environment, such as a Vagrant VM [4] provisioned with Ansible, or a Docker container [5], which generates artifacts and runs tests, is equally fine for home use. If all goes well, the release is made and the cpan-upload
script from the CPAN::Upload CPAN module then uploads a tarball created by make tardist
to CPAN.
Listing 1 [6] shows a Docker configuration that produces a clean room based on the latest Ubuntu distro. A call to Docker's build
command picks up the local Dockerfile, pulls in the lean Ubuntu base image from the Docker mothership, and adds more layers to it according to each RUN
instruction in the file:
Listing 1 Dockerfile
01 FROM ubuntu 02 03 RUN apt-get -y update 04 RUN apt-get -y install cpanminus 05 RUN apt-get -y install make 06 RUN apt-get -y install libwww-perl
docker build -t testimg .
The statements in the Dockerfile tell Docker to run apt-get update
to point Ubuntu's package manager to the latest repository versions, and to install packages for build support, such as make
. Later calls to the same build
command will reuse the previously created content from the cache, as long as the lines in the Dockerfile haven't changed according to a checksum comparison.
The build script in Listing 2 first runs the Docker build
command, which creates a new image, and then invokes the run
command that launches a container based on the image. The -v
option makes the host's source directory for the module available inside the container below /mybuild
for read and write access.
Listing 2
Build Script
01 #!/usr/local/bin/perl -w 02 use strict; 03 use Sysadm::Install qw(:all); 04 use FindBin qw( $Bin ); 05 use Path::Tiny; 06 07 my $tag = "build"; 08 my $dir = path( "$Bin/.." )->realpath; 09 10 sysrun "docker", "build", "-t", $tag, "."; 11 12 sysrun qw( docker run --rm --name buildc -v ), 13 "$dir:/mybuild", $tag, "bash", "-c", 14 "cd /mybuild; perl Makefile.PL; make test; make tardist";
Because the build
script is checked as adm/build
into the module's Git repository, Perl's FindBin
module first identifies its absolute location. The module code resides in the parent directory, and Path::Tiny
changes the location accordingly and then recreates a minimal absolute path using realpath
.
Line 13 calls bash
as a command in the container; it uses the -c
option to pass a string with the typical Perl-style triple jump of perl Makefile.PL; make test; make tardist
to it. This in turn puts together the distribution tarball from the module code under clean-room conditions. Subsequent build steps should copy the tarball to new clean rooms and test whether it can be installed and used, as this is not automatically the case, especially if it needs more modules from CPAN at run time.
Automatically Error-Free
The important thing is that each level of the build process runs automatically and immediately pulls the emergency ripcord if unexpected events occur. The automatic part is essential because human operators tire easily and start making mistakes when they continuously repeat the same steps. Broken releases are often the consequence, causing embarrassment and user frustration. If you do invest time in automating the build process, you will learn to enjoy the ability to push a button after making a change to the code, before heading off for lunch, in the assurance that everything will follow a tried and trusted path.
Tagging Releases
To later determine which state of the source tree a release is based on, the build process needs to mark the status in Git, usually with a tag that contains the release number:
git tag release_1.01 git push --tags origin
If origin
refers to the remote Git repository, the following push
command with the --tags
argument ensures locally applied tags in the Git repository get copied to GitHub for everyone to see. If you want to reproduce bugs present in previous releases later, you can get the source code's historical state during the release in question back, by checking it out with
git checkout -b testbug release_1.01
The new testbug
branch then contains the status quo at the time of authoring.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Fedora 39 Beta is Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.
-
Star Labs Reveals a New Surface-Like Linux Tablet
If you've ever wanted a tablet that rivals the MS Surface, you're in luck as Star Labs has created such a device.
-
SUSE Going Private (Again)
The company behind SUSE Linux Enterprise, Rancher, and NeuVector recently announced that Marcel LUX III SARL (Marcel), its majority shareholder, intends to delist it from the Frankfurt Stock Exchange by way of a merger.