Going forward - request for input

[erikbra]

Background

Almost three years ago, I volunteered to take over the main maintainer responsibility for RoundhousE, as it was our weapon of choice for database migrations at my employer at the time. I'm really, really happy with the tool, and we still have over 5 years of database script history, that, using RoundhousE, can spin up a new database from 0 in a matter of seconds.

The simplicity of the tool is its elegance. No complicated ORMs, in-app migrations, etc. It speaks SQL, and it handles versioning of databases. And it does it well.

Challenges

RoundhousE has been in development for over 10 years, the work was started by @ferventcoder , and he's done an amazing job. Time passing, though, some of the tools used in the beginning, and some of the external references from that time, makes it difficult to upgrade RoundhousE to current .net frameworks. In addition to this, the style originally used for writing tests, etc, BDD, is unfamiliar to me personally, and I find it difficult to expand and refactor the tool following some of the coding style, especially related to tests.

Some problematic dependencies:

• Build pipeline and tools
  • Originally using an internal chucknorris tool, but not maintained
  • "Work around" with build.ps1, but could definitely be improved
  • AppVeyor used to build, but not actively maintained
  • No automatic push of built artifacts to NuGet and others
• Third party libraries
  • log4net
  • NHibernate
  • Fody
  • Old versions of Microsoft Nuget packages
  • ILMerge
  • Oracle NuGet packages

Lack of maintainers

Many people use RoundhousE, but few contribute. The challenges are especially related to maintaining some of the lesser used database providers, especially Oracle, which has some issues, but is on an ancient version of the oracle driver. But without active maintainers with knowledge of the Oracle integrations, it's difficult to upgrade

Options going forward

My experience with maintaining RoundhousE (more or less successfully) for the last nearly three years, is that it's a bit difficult to maintain in its current state. I have plans to upgrade to .net 5 and .net 6, which brings new possibilities for e.g. distributing binaries that are single file and framework independent, so we could make distributions via e.g. apt-get and other package managers for Linux, and homebrew (or others) for macOS. However, in my opinion, that is difficult, given the current code base.

I have a couple of suggestions. Other suggestions are of course welcome - use the comments!

Option 1 - Reboot RoundhousE

Re-write RoundhousE from scratch using modern .net. Keep external dependencies to a minimal, to make maintaining the project easier going forward.

Option 2 - Abandon RoundhousE - create a new project

I have actually started on this a bit. I had a big discussion with myself on whether I should do this in the current RoundhousE setting, or start over from scratch in a separate context. I have chosen the latter, but I am open to converting this to "Roundhouse 2.0", if there are convincing arguments for doing so. I have come quite a long way, with working migrations for MySQL/MariaDB, PostgreSQL and SqlServer. (Oracle is almost working, I just can't get the connection strings set up). There are some features missing (tokenization and a few more), but I don't expect that to be difficult to implement, only time-consuming.

I plan on setting up a build pipeline using Github actions, as it's a bit more accessible, and integrated into Github.

The repo is private for now, but I will of course open up if this option is the chosen one going forward.

Opinions

What are people's opinions on this? Are there any good arguments for one option or the other? Are there other, better options? Is anyone interested in being an active contributor in either of the options above? I cannot do this alone, and I am dependent on people committing to contributing a bit of time to this on a regular basis. The more people we are, the less work it is on each one, and we can build a great product together!

Looking forward to hearing from you!

[wokket]

Having tried to resolve issues in the current codebase I completely understand the challenges in working with the codebase as it stands today.

If you're going to re-write from scratch then leaving the RoundhousE project name behind opens up much more flexibility around breaking changes... Even with a major version number bump I suspect there'd be an expectation from many users that a V2 has to be largely backwards compatible and feature comparable.

As a RoundhousE user for nearly 10 years I'd be happy to help out where I can for a workflow I love!

[Retrodad0001]

Maybe i can help out. Just started with my own migration package some days ago. EasyDbmigrator and its far from complete. Maybe i should stop that and help u guys out. My goals where that u can use it in ci/cd pipelines and in integration tests. Some rules i set for the code base: can be unittested and also contains integration test for running on dev machine, only uses default net libs and no external packages. I only use external stuff in my unittest project like xunit, fluentassertions. I only support dbs that use. Net stuff.. But that dont have to be the case if help u guys. I also use github actions for ci and later on cd stuff and auto publish nuget

[BiggerNoise]

First, thank you Erik for stepping up to take over when I went back to Ruby/Rails land three years ago.

Since there aren't a lot of contributors, I think the primary question should be, what do you think will make it more likely that you're going to want to work on it?

Certainly starting again would allow you to build it as a .NET core app from the get go with proper test & build (and maybe following the coding guidelines for C# if you're feeling really wild). Different databases could be managed as extensions, so perhaps Oracle isn't even part of core support any longer.

Taking this further, you could use the new project as an opportunity to reduce the promises that RH is making. Starting with a small set that line up with your priorities is probably the best way to avoid burning out on this.

Of course, I don't have a dog in this hunt, so you're welcome to disregard everything I said.

[erikbra]

Thanks a lot for giving your opinions, guys! And it seems we are quite aligned. I think the concept of RoundhousE is fantastic, but we are still dependent upon active and engaged contributors, on many levels. And it's been difficult to engage people the last couple of years. In addition to this, my time has been limited too, and I have sometimes been a bottleneck in getting PRs in, etc.

@BiggerNoise has a good point, that choosing the path forward that makes it more likely that people are happy to contribute is the best. And, to me being able to work with the latest technology, experimenting with new .NET and related features, and not be bound by legacy dependencies is definitely a plus.

So, I think this settles it, that we'll prioritise the new project, and leave this one behind. I think postponing the "abandonment" until we have released a first version of the successor is a good idea. So we'll leave this repo as is for now, imho.

@wokket and @Retrodad0001 , would it be OK if I invite you to my repo with the new project, I've named it Grate, as in (mi)grate, and because it's (going to be) a great/grate product ;) and we can discuss a bit further there what you are able to contribute with, etc? The project is private for now, but I'm thinking of opening it when we feel we're ready for it.

Any other contributors are, of course, more than welcome, just give me a shout out!

[wokket]

@erikbra feel free to flick me an invite 👍

I'd absolutely leave this repo here:

• It's still an awesome, working tool in the meantime (just a bit harder to change than we'd like)
• It's an easy way to redirect traffic to a newer tool in the future if you want
• Historically I think there's value given the perma-link nature of the internet

[OzBob]

@erikbra As a new user to RoundHousE I'm excited to see it is being actively improved.

I'm assessing DB Migration technologies for our growing company, I will continue my search and if I can come back and see how Grate is coming along, I will.

My feedback for the new repo is keep an eye on the User Story for new users, ie. look at Getting Started in the wiki.

The latest zip from /releases doesn't have a "LOCAL.DBDeployment.bat", so it's a bit of a blind start for a new user.

[erikbra]

To the ones following, grate is now open to the public. https://github.com/erikbra/grate/

Built from scratch with .NET 6, and other modern libraries. @wokket has been an invaluable contributor. I invite the others of you to join as well!

//cc @OzBob @Retrodad0001 @BiggerNoise

Not all RoundhousE features are implemented yet, but it's quite functional. It' available as a dotnet command-line tool.

https://www.nuget.org/packages/grate/

Other release channels are planned, but for now, you can binaries from a build as well, e.g. here: https://github.com/erikbra/grate/actions/runs/1275973062