Skip to content

Going forward - request for input #438

@erikbra

Description

@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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions