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:
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 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.
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.
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.
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.
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:
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.
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.