Agola talk at the CNCF Kubernetes Milan Meetup
Agola talk at the CNCF Kubernetes Milan Meetup We gave a talk about Agola at the CNCF Kubernetes Milan meetup For everyone interested you can find the slides in pdf format here
Agola Direct Runs: Power to the Developers!
Agola Direct Runs: Power to the Developers! When we started drafting the big list of Agola wanted features, one of the primary requirements we heard from many developers was the ability to execute the agola Runs (or pipelines/workflows in other CI/CD tool concepts) from their local development directory while they were developing new features at any time (and without the need to commit). There are many good reasons to ask for this:
Building and pushing docker/OCI images with Agola and Kaniko
Today a common need is to build and push docker/OCI images in your CI/CD system. One of the primary issues users are facing when doing this is how to build images inside a container (Agola by default uses containers to execute run tasks). This usually requires using docker-in-docker and so privileged containers or bind mount the host docker socket. These choices can face some security issues or break the container isolation.
Introducing Agola: CI/CD redefined
Introducing Agola: CI/CD redefined There’re many CI/CD tools outside, some of them are available only as SaaS (and many are free for Open Source projects but some of them are closed source), others are open source and you can install them wherever you want. So: why another CI/CD tool? At Sorint.lab we used many different CI/CD tools for years, our Open Source projects usually use free SaaS tools, internally and from our customer we used Open Source tools installed on premise.
Approaches to implement CI
Part 5 of “From Chaos to CI/CD” After many years dealing change projects in the development processes with successes and failures… we learned at least that it’s a continuous learning exercise! When the successes come there is no magic involved, no magic wand (tools) only commitment sharing experiences, failures and critical points… The magic behind it. Well I wrote no magic involved but I think we can call magic some points I’m going through in this post.
Metrics you need to measure for development process success
Part 4 of “From Chaos to CI/CD” Creating an innovative development process is not enough, we must be able to measure it effectively so that it can always improve (Continuous Improvement). Benchmarking the current process is essential to measure subsequent automation successes. One of the most common metrics is to calculate the number of defects, but it is not enough, we must also verify other aspects related to the build, the coverage of the tests, the speed of the process.
A Brief Introduction to CI
Much is said about agile methodologies, but there is a need to use some techniques for these methodologies to succeed, one of the techniques is Continuous Integration. The continuous integration is a term originated in the agile methodology XP and used in other methodologies, consisting in a simple goal: the developer integrates the code altered and / or developed to the main project in the same frequency with which the functionalities are developed, being done many times to the per day rather than just once.
Why agile development creates more problems than it solves
Part 2 of “From Chaos to CI/CD” Put down your pitchfork, we at Sorint.lab love developing software using an agile approach. We adopt SCRUM for most of our projects and we are pleased by the results. The Agile Manifesto ultimate goal is to satisfy the customer, who wouldn’t want to do that? The agile approach suggests frequent software releases and promotes a strong customer interaction to overcome a few common hindrances of a more traditional methodology:
FROM CHAOS TO CI/CD "Our experience with CI/CD Implementation"
Our mission is to help companies to implement DevOps; challenging the status-quo and evolving software product lifecycle and software development approach. The goal of these series of blog post is to share openly our experiences asking for feedback from whom out there has the same mission. Thanks for reading and commenting. PART 1: The Context In this blog, a team of solution architects, software architects and enterprise architects within Sorint.
An introduction to stolon: cloud native PostgreSQL high availability
At sorintlab, in the old days and with customers with “old school” infrastructures we had different ways to make an high available PostgreSQL. We used heartbeat, heartbeat+crm, rhcs, coreosync+pacemaker with a shared storage and a correctly (!!!) configured fencing/stonith. When moving our infrastructures and customers to cloud based infrastructures (being it a private or a public one), the way to design the infrastructures drastically (and fortunately) changed. Finally our customers were forced to think about the various parts of the infrastructure like something that can break in every moment and that’s also ephemeral.
Categories
Tags
- agile
- agola
- approach
- assessment
- automation
- best-practices
- build
- ci/cd
- cloud
- code-quality
- consul
- devops
- direct-runs
- distributed-system
- docker
- etcd
- git
- gitea
- github
- gitlab
- go
- high-availability
- iaas
- kubernetes
- meetup
- methodologies
- metrics
- microservices
- oci
- postgresql
- push
- runs
- scrum
- software-development
- stolon