Automate it when it matters

Back to 2017, Starsellersworld want to develop a new tool for people working in the seller’s store and dealing with shipments directed to customers.

One of the key work behind every online sellers is to pack and ship the package to the customer, as soon as the order is received, accepted, and invoiced.

As a SaaS for online sellers (say e-commerce owner), Starsellersworld supplies services to automate the pre-sales and post-sales. To simplify, it translate to reprice (and win buybox on Amazon and other platforms), and to rate suppliers and level of service. Other than this, the shipment is a key factor to optimise the performance and time-to-customer value (an important metric for the platform rating).

How does shipment people work

Most of the time, an Online Seller is not just an Online Seller, it is “also an Online Seller”. This means that the seller has the real mall where he make deal with real people, and also publish its catalog online to improve total selling volume.

An employee working for that seller, in general is involved with closing deal with people.

In the sparing time, it can then work on:

  • check online orders
  • pack each order that is ready
  • put the shipping label on it
  • stack that pack in in a pile ready to be taken by the shipping company (say DHL)

That said, from the SaaS point of view, what Starsellersworld provide is

  • generation of a picklist: list of all items that are needed to satisfy all orders in “to be shipped” state
  • generation of a packlist: list of items related to a single package

PackPickMan

Thus, the project was named “PackPickMan”: I am responsible to “pick” that name. I have to say I was frightened by Atari case (even if, yes, this is “Pack”, not “Pac”). Anyway the right order were to Pick-list, the Pack-list, then Man-age the order (and ship).

This is an annotated GUI, during development:

PackPickMan is a desktop, Electron based, application, with codebase in ReactJs.

Development cycle and deployment

Once the first idea was ready (around April 2017), the problem was to speed up deployment and scrutiny by beta-tester.

On first month I just cross-compile Electron application on my machine, and uploaded the binary into a folder of starsellersworld webserver.

But it was very boring, time consuming, and require me to keep my laptop switched on for cross-compile. Also I have to take care to move the files into the target folder.

Gogs + Jenkins (on Docker Swarm)

This was the first time I need it, and I just take some containerised app to run into docker swarm. At the time I had little experience on this, but I know about docker composer, and docker swarm just accept the same format. The configuration was straightforward, on each push into the Gogs, an Webhook was triggered, that ping a job defined in Jenkins.

What I had to care was to add “Jenkins” as a gogs user, with read access to the repository, so it can checkout and execute the pipeline.

The Pipeline file was on the repository itself, and it was surprisingly simple:

pipeline {
agent {
dockerfile {
args "-v ...."
}
}
environment {
CI = 'true'
ELECTRON_BUILDER_CACHE = '/home/individul/.cache/electron-builder'
ELECTRON_CACHE = '/home/individul/.cache/electron'
}
stages {
stage('Prepare') {
steps {
sh 'yarn'
}
}
stage('Build Packages') {
steps {
sh 'yarn package'
sh 'yarn package-all'
}
}
stage('Upload') {
steps {
sh './jenkins/scripts/upload.sh'
}
}
}
}

The Dockerfile was in the repo itself


FROM electronuserland/builder:wine


RUN apt-get update -y
RUN apt-get install libcups2-dev

RUN npm install -g n
RUN n 9.11.1

Still very simple.

The outcome

Apart from fighting the (little) resistance for deploying new services on server, the resulting workflow (and life quality) was very positive: I just need to push newer version when I implemented some new features.

On other hand, this was the jump into a new field. Together with Gogs and Jenkins, I also deployed Redmine for project management, and also redmine was running on the same docker swarm. Then I started to add traefik to better handle the traffic to each tool.

As the years go on and by, Starsellersworld started to have a deployment pipeline that speedup development on all side. In the middle of 2018, I deployed Gateway manager for Docker Swarm, at the end of 2018 I automate the deployment of a React version of the WebGUI (it was still on jquery based), and it was based on JWT and REST API Backend provided by the new Gateway Manager (and the service behind, running in the docker swarm).

All that happens just to skip the boring staff of manually distribute a desktop executable.