Member-only story
Why We Stopped Using So-Called Best Practices in Our CI/CD Process
Or reasons to avoid npm and deny the Google Play process
Preamble
At Kalisio, we develop open-source geospatial software — that’s to say, software that manages geolocated assets but in a more friendly and business-oriented way than GISs usually provide. We’ve built a strong ecosystem composed of various tools and applications, providing dozens of web services to deliver our solutions as SaaS:
- Kaabah, a solution to build and operate Docker Swarm infrastructures
- Kargo, a Docker-based solution to deploy geospatial services
- Krawler, a minimalist extract-transform-load (ETL) tool
- Weacast, a platform to gather, expose, and make use of weather forecast data
- KDK, a development kit to simplify building geospatial web applications
- Kano, a map and weather-forecast data explorer in 2D/3D
- Akt’n’Map, an application to manage real-time events on the field
Applications like Kano or Akt’n’Map have been developed as a set of loosely coupled modules using the KDK to prevent building a monolithic piece of software, ensure separation of concerns (SoC), and ease maintenance, at least from a source-code perspective.
Moreover, we manage dedicated infrastructures with different instances (e.g., configuration) of these solutions to be able to simultaneously run our own production version, beta version, and alpha version — in addition to customized versions for some of our customers. As a consequence, we need to rely on a predictable and mostly automated process to release our applications.
CI/CD pipeline
The main purpose of the continuous integration and deployment (CI/CD) pipeline is to create/build application artifacts (Docker images for web applications and mobile-application bundles) and deploy them into production-like environments in order to use/test them.
