eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Server stats:

223
active users

#cicd

1 post1 participant0 posts today

To continue our Bastille Day release extravaganza we're also announcing Rocinante 1.0 series is now available! :freebsd:

This release brings most of the Rocinante commands up to par with Bastille functionality and now includes a `bastilletesting` directory which has been designed to validate code changes in both projects.

Bastille and Rocinante can now be combined to build simple CI/CD pipelines to validate deployments!

Okay, CircleCI is actually pretty dang nice to work with, it's more intuitive than many other CI/CD platforms in its syntax and docs are concise and easy enough to navigate.

Especially like the way they've done the workflows, as it makes orchestration ...easy? Combine that with plugins for major platform deployments suddenly you can do more with one file than some folders of shell scripts and config files :neocat_glasses:

"Continuous AI is a label we've identified for all uses of automated AI to support software collaboration on any platform. Any use of automated AI to support any software collaboration on any platform anywhere is Continuous AI.

We've chosen the term "Continuous AI” to align with the established concept of Continuous Integration/Continuous Deployment (CI/CD). Just as CI/CD transformed software development by automating integration and deployment, Continuous AI covers the ways in which AI can be used to automate and enhance collaboration workflows.

“Continuous AI” is not a term GitHub owns, nor a technology GitHub builds: it's a term we use to focus our minds, and which we're introducing to the industry. This means Continuous AI is an open-ended set of activities, workloads, examples, recipes, technologies and capabilities; a category, rather than any single tool."

githubnext.com/projects/contin

GitHub NextGitHub Next | Continuous AIGitHub Next Project: Exploring LLM-powered automation in platform-based software collaboration

"DevOps is more than just a methodology. It is a cultural shift that blends software development (Dev) with IT operations (Ops) to create a more efficient, collaborative workflow.

The goal is to break down traditional silos between teams, enabling shared responsibility for software performance, security, and delivery.

Having adopted DevOps principles myself, I can say they really transform how teams build and deploy software. That’s why, in this guide, I’ll will walk you through a step-by-step roadmap to help you master DevOps."

datacamp.com/blog/devops-roadm

There's a lot of "Reminder; don't deploy to production on a Friday" messages going around.

A counter PSA: deploy on a Friday. Deploy whenever. Deploy little. Deploy often.

If you're frightened of your deployments, then take a hard look at them. Don't just _stop_.

Thrilled to have a new, production-ready CI/CD pipeline live! It automatically builds and deploys my Jekyll static WIP site (hofstede.it) on every push to the main branch.

The architecture is a showcase of modern Linux tools:

🔹 Server running on Red Hat Enterprise Linux 10 (RHEL)
🔹 Forgejo for Git hosting & Actions.
🔹 A rootless Forgejo Runner, running in Podman, managed by a systemd Quadlet file.
🔹 Traefik reverse proxy running as a Podman container.
🔹 An Nginx web server for the site, also in a container for easy discovery by Traefik.

The Forgejo Runner and the Nginx Webserver run in different unprivileged user contexts.

The magic is the secure bridge between the rootless CI job and the web server. The pipeline creates a build artifact, and a systemd.path watcher on the host instantly triggers a deployment script.
It's fully decoupled, secure, and works like a charm.

CI/CD pipelines for dummies.

First, make separate pipelines by area, f.ex: Frontend, Mobile (android/iOS), Backend.

Then, add default jobs:

  1. Static Analysis (linting, code quality)
  2. Tests (run and measure coverage)
  3. Security (scan code, dependencies, container and report)
  4. Build & Release (tagged)
  5. Deploy

Avoiding overhead by:

  • Run job 1 for all branches
  • Run jobs 1-4 for develop (unstable)
  • Run jobs all for staging (testing) and production

And finally, when releasing:

  • Use semantic versioning, i.e. Major.Minor.Patch
  • Keep a CHANGELOG.md
  • Use secrets for sensitive info

Once this is in place, then you can start thinking about agent-scaling, dynamic test environments for pull-requests and the plethora of integrations/plugins/etc that exist for each CI platform.

#CI#CD#CICD

CircleCI seems a lil'pricey but like a decent option for my team :neocat_think:

Like, it seems like the costs can be kept reasonable by using a self-managed runner for dev-builds, and use the managed runner for releases.

And having native integrations for our hosting provider, deployment methods and all of our targets certainly helps to make things easier when we have no dedicated DevOps in the team (yet).

Now to figure out if there's some past bad behaviours or other kind of black mark on it I should be aware of...

#circleci#devops#ci