Share your experience using Canonical Bazaar

I use GitHub as my Git versioning platform, and my repos are also hosted on GitHub. I am using GitHub for versioning in my team.

I manage branches and pull requests using GitHub with strategies for deployments and merging, utilizing feature branches and permissions with approval gates for production deployments.

GitHub offers the best features including Git versioning, pipelines, Actions, version control, security, collaboration, PR management, and dependency management.

Collaboration, security, and version control, along with GitHub Actions, have had the biggest impact on my daily work.

I use some features less often, such as the secret and environment creations.

This workflow has improved my team's efficiency and collaboration by allowing us to plan deployments accordingly and easily roll back if something goes wrong.

GitHub has positively impacted my organization, helping to improve the productivity of my team and reducing errors in production.

If GitHub could support a GitOps approach for managing my Kubernetes clusters, that would be very helpful.

I have been using GitHub for almost seven years.

GitHub is stable.

GitHub's scalability is fine; I can customize it and have my own kernels.

The customer support does a great job, and I am happy they find solutions for my issues quickly. I would rate the customer support as a seven.

I started with GitHub, so I did not use any other options.

I was able to save time during deployments and optimize my spending, which helped me reduce costs.

I am happy with the pricing, and the setup cost is pretty much just a flat setup cost.

I checked other options before choosing GitHub.

I would rate GitHub as an eight overall.

Since GitHub has the features and functions I need in a DevOps bundle, I would say eight.

Regarding GitHub's AI capabilities, I find its documentation up to date, the governance transparent, and the security very much fine.

I am satisfied with GitHub's accuracy because whatever details I am getting are accurate and reliable outputs.

I am using GitHub in my private cloud, and sometimes I am using it in the public cloud as well.

My cloud provider for public or private deployments is Azure and AWS.

Since GitHub is a free solution, I advise others to start with their services, and for heavier workflows, you can run on your own runners as well.

My main use case for Liquibase is because, for our product NormaPro, we have different databases and different data schemas for each of our clients. The database, apart from the table architecture and so on, has a lot of business logic embedded within functions and procedures. Liquibase is our main solution for new client provisioning, for deployments of the entire database architecture and all functions and procedures, to find differences between the different database schemas of our clients, and to apply updates and fixes.

Before having Liquibase, we had no control over the software that was running in each of the clients' schemas. Liquibase has provided us with a quick way to find errors in those clients where functions or procedures were outdated.

Every time we have a deployment for a new client, Liquibase, by working like GitOps for database-related matters, makes deployments and the creation of new schemas enormously easier for us.

The best features that Liquibase has are database engine abstraction, programmable code re-execution, granular deployments with contexts and labels, the automated rollback strategy and, above all, inspection and diff and baseline generation.

The rollback strategy allows us to roll back certain deployments that have gone to production with errors. In such a way that we always have a possible mechanism to roll that step back to the previous version for everything related to functions and procedures and table structure inside the database. What I like most about rollback is that we can define a rollback block directly in XML or YAML and Liquibase understands perfectly where it has to go back.

By minimizing errors, minimizing time, with an incredible cost saving, eliminating database incidents, having a diff inspector against our baseline to know which client schemas are outdated or not up to date, to know what differences there are between the different schemas, this has produced an immense cost saving for us. Before, it was very manual, very tedious work and very prone to errors. I have a metric, I have a KPI on errors produced in the database. These errors have decreased almost to zero since we have been using Liquibase.

The syntax, especially as it is agnostic, is not always 100% transparent. In heavy object management, there should be improvements, and when we have large-scale multitenant environments, the orchestration becomes a bit tedious. But basically, for my use case, it is a tool I recommend 100%.

For object management, the problem is the checksum, which has a very strict and sometimes rigid handling. Even if runOnChange is true, helping stored procedures when the code changes, any minor modification or formatting change should be a bit easier.

Liquibase flawlessly solves provisioning, maintains consistency between dozens of schemas, has database version controls integrated into Git, has enormous reliability in auditing. However, it lacks native multitenant orchestration, it has a lot of rigidity in checksum management with programmable code, and the use of native SQL within XML does not work entirely well. I give it eight out of ten because it is indispensable and unbeatable for guaranteeing consistency and automatic provisioning in our multitenant architecture. I only deduct a couple of points for the lack of native multitenant orchestration and the occasional rigidity of checksums when modifying MySQL functions.

We have been using Liquibase for more than four years.

Liquibase is very stable.

Liquibase adapts very well to our scaling needs. I would rate it a ten.

The documentation is clear, concise, and I can find everything on their website.

We previously used migrations within NodeJS, but when the product started to scale and we had more and more clients and more schemas, the solution did not seem feasible.

Basically, what we launch is a pipeline where all the database changes are provided and Liquibase is responsible for coordinating and controlling all the schemas of all clients to apply the changes to all of them at once.

We have an ISO 27001 certification and within the specifications of the standard, we have change management where there is a specialized team for database changes, basically in charge of coordinating all movement with Liquibase. Only they are the ones who have access to this tool and to put changes into production regarding databases.

The license versus the return on investment that we have had is very substantial.

Liquibase costs us thirty-three dollars a month. Basically, in the past, before having Liquibase, finding any error in any client's database would mean hours and hours of a database expert, which would cost us much more than thirty dollars. Much, much more.

We evaluated other options. We evaluated, for example, Flyway, Redgate, and DBmaestro, but Liquibase convinced us because of the price and the direct functionality we were looking for regarding migrations.

I should not hesitate to recommend Liquibase because if you have an environment like ours, where you run many databases, each one for each client, to maintain consistency with the version that is running, it is an essential tool. Liquibase is great software that makes life and maintenance of client databases easier. I give this product a rating of eight out of ten.