Wednesday, 21 November, 2018 UTC
Summary
A Q&A with Jon Sharratt, co-founder of Sail.CI.
What are you building at Sail CI?
Along with my co-founder, Chris Shepherd, we are building a Kubernetes cloud-native continuous integration platform with unlimited concurrency as standard.
Using Docker images as tasks, you can build complex workflows using the 100,000+ images available on Docker Hub and other providers.
For too long CI products have had high prices and charged teams for usage even when they are not in use. Sail CI offers pay-per-minute and unlimited concurrency as standard. Teams never need to be blocked ever again.
We have used many CI tools, and there is a lack of trust with the vast majority of the user experience when it comes to showing the correct real-time information. Making users refresh pages makes them lose any trust in any capacity in your CI tool, and also has detrimental long-term effects for your team.
Why did you choose to go with Postgres and GraphQL?
For Sail CI we decided on using GraphQL as we wanted to offer a flexible API that our customers can use and also build their own experiences with.
Our experience with Postgres in previous projects has been incredibly positive. Postgres keeps getting better every year and was a natural fit for our team to be productive and deliver value from the get-go. For context, our UI and GraphQL API are all using Node.js.
The Sail CI architectureWhat made you choose Hasura when building Sail.CI?
We started looking at how we could get up and running quickly. Our first iteration to manage database transactions and models was a Node.js ORM called Sequelize — very much a familiar concept to those using something like Active Record.
We found that it was becoming quite a time sink to create a testable and flexible model. When you start projects, your database schema is going to change rapidly, and it quickly becomes apparent that using an ORM becomes tiresome when testing and iterating.
We started to look at options for a different approach using GraphQL on top of Postgres, with our own public GraphQL API and then communicating to it directly internally within Kubernetes. It meant we could control the public API schema and look to provide a secure and concise API for users and developers.
I checked out a few options for GraphQL over Postgres, but ran into technical problems around performance and high availability. It was then that Chris pointed me towards Hasura.
We started playing with the UI and fell in love straight away. We were initially dubious about a UI that records migrations, but it has worked flawlessly. In comparison to a traditional ORM, we can sketch out schemas up front to see if it fits our needs. If it does, then we start the console and record them. Very valuable to refine and iterate quickly, it has hugely increased our productivity and resulted in a better database schema for our application.
What has your experience with Hasura been like?
We started using Hasura at v1.0.0-alpha13 and so far even with upgrades we have had no issues. The team is super helpful and on Discord for any questions. We can’t recommend highly enough how great the team is along with their attitude.
They really should come out of alpha now, Hasura is a very polished and solid product in our eyes.
What is on the roadmap at Sail CI, and how might Hasura help?
Our roadmap is very exciting; we just announced Sail Connect where you can run the workflow engine Sail CI uses at its core on any device that can run Kubernetes.
We are looking forward to having integrated dev tools for code editors that teams can use with live updates coming from our GraphQL API. A new visual workflow builder will empower teams with all kinds of creative and exciting possibilities.
We are also expanding our UI significantly for teams. We are looking to provide a best-in-class environment for collaboration with continuous integration at its core; saving a ton of money and putting metrics and measurement at the forefront of the software delivery process.
We may move to expose Hasura directly as things with Hasura moved on very quickly from v1.0.0-alpha13. Events didn’t exist back then, so we are looking to see if that is something we want to do going forward. Our entire platform is event-based and appears to coincidentally be in line with Hasura’s 3-factor app architecture. We are looking to test if exposing the Hasura API directly is something a developer would prefer.
If you would like to keep up with updates as we build out the best in class CI tool for teams, you can follow us on Twitter, Discord, or through our website.