It seems to be a lighweight project. It's perfect for small projects!

Setup SSH on a server

Static web publishing for Front-End Developers

That's great to have such simple deployment. Maybe one for rust with such a script or command could be great too.

Or a bash script :)

The author shares its point of view on Shuttle that needs little to nearly 0 configuration to get started.

Zerocal was the first project I deployed on Shuttle. The principle was very simple yet innovative: encode calendar data directly into a URL. [https://endler.dev/2022/zerocal/]

#project #idea improve the UI or make a custom one that calls the API
#project #idea use such API to generate other files. Contacts?

Le jour où je n’au­rai plus aucun inci­dent ni anoma­lie, je consi­dé­re­rai qu’on a mal fait notre travail en surin­ves­tis­sant dans la qualité par rapport à nos besoins réels.

Et si j’as­sume d’avoir un risque casser des choses, ce n’est pas décon­nant de choi­sir quand je veux gérer ce risque. La règle de la mise en produc­tion du vendredi, pour les équipes qui en ont une, n’est parfois que cela.

Lint Github workflow files

How much uptime guarantees should be needed?

A crash course with further resources

On a 4-core machine, running all our tests sequentially would take 3 days, 15 hours, 10 minutes, and 3 seconds. It’s extremely difficult to run a subset of tests since we’ve built a pure monolith with deeply interwoven concerns, so we run every test on every push of every PR … in only 18 minutes!

Docker-compose is a tool that accepts a YAML file that specifies a cross container application and automates the creation and removal of all those containers without the need to write several docker commands for each one. It should be used for testing and development.

Kubernetes, on the other hand, is a platform for managing production-ready containerized workloads and services that allows for declarative setup as well as automation.

I will read more when I will need it :)

Unit > Integration > E2E is still a valid pyramid for testing; but better can be found.

Static analysis > Unit + Integration > e2e

Static analysis means to check the code without running it. We already have examples with Eslint as a javascript code style fixer; Stylelint for CSS code fixing (I have to try); Sonarqube

Unit and integration tests are mixed together as:

• The definition of a unit is often “to be discussed”: If you ask a group of developers to define a unit, you will mostly get various, differing answers. As some refer to a function, class, or service — minor units — another developer will count in the complete component.
• In addition to those definition struggles, drawing a line between unit and integration can be tricky, as it’s very blurry. This struggle is real, especially for Frontend, as we often need the DOM to validate the test basis successfully.
• It’s usually possible to use the same tools and libraries to write both integration tests. So, we might be able to save resources by merging them.

There are also visual tests. We can group e2e-tests and visual tests into a UI test category. Btw the recommended open-source and fully self-hosted tool for visual testing is Visual Regression Tracker

CI looks like build systems. If you push a CI system or a build systems too far, they seem to be the same as what they are doing.
The thing that bugs me about modern CI systems is that I inevitably feel like I'm reinventing a build system and fragmenting build system logic.

So going beyond the section title: CI systems aren't too complex: they shouldn't need to exist. Your CI functionality should be an extension of the build system.

CI offerings like GitHub Actions and GitLab Pipelines are more products than platforms because they tightly couple an opinionated configuration mechanism (YAML files) and web UI (and corresponding APIs) on top of a theoretically generic remote execute as a service offering.

I'm convinced that building what I'd like to see is not a question of if it can be done but whether we should and who will do it.

In my ideal world there exists a single remote code execution as a service platform purpose built for servicing both near real time and batch/delayed execution. It is probably tailored towards supporting software development, as those domain specific features set it apart from generic compute as a service tools like Kubernetes, Lambda, and others. But something more generic could potentially work.

Conclusion:

If I could snap my fingers and move industry's discrete build, CI, and maybe batch execute (e.g. data pipelines) ahead 10 years, I would:

1. Take Mozilla's Taskcluster and its best-in-class specialized remote execute as a service platform.
2. Add support for a real-time, synchronous execute API (like Bazel's remote execute API) to supplement the existing batch/asynchronous functionality.
3. Define Starlark dialects so you define CI/release like primitives in build tools like Bazel. (You could also do YAML here. But if your configuration files devolve into DSL, just use a real programming language already.)
4. Teach build tools like Bazel to work better when units of work that can take minutes or even hours to run (a synchronous/online driver model such as classically employed by build systems isn't appropriate for long-running test, release, or say data pipelines).
5. Throw a polished web UI for platform interaction, result reporting, etc on top.
6. Release it to the world.

Utiliser Renovate pour gérer la mise à jour de ses dépendances. Sur Github et Azur, cela se fait en un clic. Ici pour Gitlab, une installation préalable est nécessaire.

The official website: https://dagger.io/

Sounds promising. Every devOps tool is a node in a graph, and we can plug-in everything: CVS, scripts, APIs, CD/CI, other tools.

SDK > API car les SDKs (ou bibliothèques) permettent aux utilisateurs d'avoir moins de cas à traiter. Exemple d'AWS.

Avec une API, toute la partie gestion du réseau et des requêtes est à faire.