-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How do we make LambdaCD more approachable? The structure of the ecosystem #191
Comments
As one evaluating the project right now I would say simply pointing out recommended relevant libraries in the docs would go a long way towards making it approachable. For example right now I'm stuck with things like:
The Getting Started guide already assumes people would come to LambdaCD from outside the Clojure ecosystem, so we should be forgiving not knowing how things are done here :-) |
My little thinking about this topic is what make lambdacd better than others? Solving outstanding CI/CD big issue would be a good way to make lambdacd become unique. Something like testable ci/cd pipeline would be awesome!
|
Sparked by #190:
My initial plan was to build LambdaCD in a way that it is easy to extend or swap things out and build most functionality that's not necessary in the core as separate extensions. That was motivated both by general design concerns (Unix Philosophy of one piece doing exactly one thing well, Libraries, not frameworks, ...) as well as the hope of sparking a community with different pieces being maintained by different people. This had mixed results:
Clearly (as you have observed), separating stuff into many different libraries makes LambdaCD much harder to handle for users (need to find the right libraries, make sure the versions match up, ...) and LambdaCD-Developers (interfaces between libraries, keeping stuff in sync, where does something go,...).
Also, the idea of a larger community owning parts of the ecosystem never really materialised. There are a couple of libraries out there built by others but often not very actively maintained. The rest is owned by me with the occasional PR.
On the other hand, I have seen some successes of the general design and it might be LambdaCDs biggest strength: Some people don't use LambdaCD as a monolithic tool they just deploy onto a machine. They use it as building blocks to build their own internal, custom delivery tool. To be fair, this audience is probably not that big.
Long story short, I wouldn't want to fundamentally change the design ideas but there's definitely room for improvement in making it more approachable for newcomers.
Here are some ideas:
lein new lambdacd
to become a true, batteries included "LambdaCD distribution". Also invest in the infrastructure around it (e.g. proper pipelines to make sure the different pieces fit together, maybe a common github organisation).The text was updated successfully, but these errors were encountered: