Bob CD | Hacker News Reader

Bob CD

bob-cd.github.io

52 pointstodsacerdoti45 comments

People should expand acronyms at least one place somewhere on the page. I'm now three clicks deep and looking through the youtube comments and still a bit vague as to what this is. CI/CD? Thats continuous integration right? Should everyone know thats what CI stands for? I'm sure its a very useful thing but I havent personally ever used it even though I've been a programmer for 40 years. So I'm not that famailiar with the acronyms. My point being - our industry is big and not everyone uses every thing, or knows what it is, so its useful to expand acronyms somewhere in the description.

Agreed that CI/CD should be explained, or at least hyperlinked. However, in their minor defense, they are following the example of GitHub Actions (https://github.com/features/actions) which also does not explain those terms. But at least GitHub Actions does explain it in the docs (https://docs.github.com/en/actions).

My problem is that I know what CI/CD is, I have used a handful of popular implementations of CI/CD (e.g GitHub Actions, BitBucket Pipelines). But after clicking through most of the pages on the Bob CD website, I don't understand what exactly Bob CD does or how to use it. Is it local (like Jenkins), or is it cloud based (like GitHub Actions)? How does it integrate with my local git repo, or my GitHub or GitLab account? How do I trigger the pipeline? How do I specify the actions of the pipeline?

It feels like Bob CD website makes sense only if you already know how to use Bob CD.

(edit: fix typo)

I think the website could be clearer, but the use case is already pretty clear: it's a foundational piece for you to build your own CI/CD infrastructure, it doesn't provide a complete experience out of the box. The first section says the following:

> Bob allows you to build your own custom CI / CD infrastructure thanks to it's composable architecture, allowing you to use Bob for various different purposes

The "Why" page goes further and explains what Bob is, so what is not described there, it doesn't ship with, like a UI, which would be up to you to decide which UI to use, or to write your own (or skip fully if you don't need it, maybe just use IRC/Matrix/Discord/Slack notifications?) https://bob-cd.github.io/pages/why-bob.html

> It feels like Bob CD website makes sense only if you already know how to use Bob CD.

Just as a disclosure; I have never heard about Bob CD since I read the linked website from this submission, so no previous experience. And I think I grok it pretty easily, although I've built and maintained more CI/CD integrations/platforms than I care to count at this point, so probably biased a bit.

Thanks, your post seems more clear than the website: Bob is for people who build CI/CD, not for people who use CI/CD.

hello, the author here! all of these points have been taken as valuable feedback and thanks a lot for this! what @capableweb said is pretty much the goal of bob, primarily originating from my experiences with various tooling along my career and pretty much built in my free time. would love if more people have a similar perspectives and would love to see it in a more formal way that just a way to solve my problems :) and of course happy to collaborate and PRs most welcome! :D

For anyone else annoyed by the replies that complain everyone should know what it means and don't bother to actually answer:

"In software engineering, CI/CD or CICD is the combined practices of continuous integration (CI) and (more often) continuous delivery or (less often) continuous deployment (CD)." https://en.m.wikipedia.org/wiki/CI/CD

Or simply:

- CI can build your app and run tests on each commit or manually.

- CD can deploy your app (copy files to some host, pull newest docker image, do any additional steps necessary) on each commit or manually to dev/test/prod instances.

It enormously frees up your valuable brain cycles and you feel excited instead of "eh, there it goes again, how i'm not liking deployments..." whenever you want to deploy.

If you have `make build` && `make test` or similar script, that runs your tests, congrats, you have local almost-CI doing the hard work for you.

If you have `make deploy` or similar script that makes deployment easily, congrats, you have a local CD doing the hard work for you.

Except server software enables you to run builds/tests/deployments even when your computer is off or your colleague forgets to run make test.

> - CI can build your app and run tests on each commit or manually.

"Simply" while getting it wrong? :D

What "Continuous Integration" is hides in the name of it, you continuously integrate the code into the "main branch/trunk", meaning if you have multiple contributors to a project, they frequently all merge the code into a common place where they base their next changes from.

"Continuous Deployment" is taking CI to the next step where you frequently deliver those integrated changes to your user. Deploying every commit to a testing instance wouldn't actually be CD as your users usually don't hang around on your testing instance. If you frequently push changes to production though, where users can use it, then you are "continuously deploying".

To make things even more confusing, CD can also refer to "Continuous Delivery" which is essentially the same as "Continuous Deployment" except you don't actually deploy to production, you just pretend to all the way up to actually updating the software on the production server. You do this in order to always be ready to deploy whenever, but when you don't feel safe enough to get there just yet.

Building and tests are not even needed for CI nor CD, although it helps tremendously and it would be foolish to attempt CI/CD without any sort of automated tests.

Thanks for clarification, then it turns out to be simpler per your definition: Basically, git with remote origin is CI :) In this case, I'm pretty sure people that don't care about CI uses CI, but they don't care how its called.

Why stop at acronyms? Everyone could add a definition for every word the first time they use it? Or maybe they can assume that since you're reading a webpage you have access to the internet, and could easily look up any words that you don't know.

Words often have one (or a few) largely agreed-upon definitions. Acronyms are often overloaded based on context, and are less likely to be known by a casual reader.

NASA probably doesn't need to be expanded, because even if you don't know that it's the National Aeronautics and Space Administration, you do know that they make the up-goers.

CD could mean a bunch of things, all context dependent. When it's paired with CI, it becomes easier to guess, but "Bob CD" doesn't tell me anything useful by itself.

If the page just said "Bob CD" without elaborating, I'd agree. But it does go on to describe itself as a "CI Platform", having "Pipelines/Artifacts/Resources" and so on, so you can be pretty sure it's not talking about "compact discs" or whatever.

By the way, how to you feel about "ycombinator.com" not really describing that it is just a startup accelerator and not about the lambda calculus combinator?

The very first text my eyes fell on when visiting ycombinator.com was:

> Y Combinator created a new model for funding early stage startups.

That is a great example of a landing page that actually tells you what's going on.

That could apply to a cryptocurrency DAO as much as a startup accelerator. Why not just say how the funding works instead of masking it in that way?

I sit in the 'Writing Best Practice' Cafe, sipping my latte. Outside I see a straw man slide down a slippery slope.

You didn’t know an extremely common acronym in our industry. You have absolutely no room for this level of ego.

Seriously though, all I'm saying is that its good to define acronyms somewhere on a landing page. It can be at the bottom. In the footer even. This shouldn't really be controversial.

You're sortof asking how could I not know what CI is. So I'll expand on that a bit.

- firstly, it doesn't matter if you think everyone knows it, the industry is deeper and wider than people think. So its polite and good practice to define acronyms. Granted part of the problem here is that this hit the front page of HN so the audience suddenly became a lot wider than the author perhaps expected.

- me, personally, in my 40 years I've encountered continuous integration but not enough to see the letters CI and immediately think of CI. And when you encounter a random link on HN it could be anything. Maybe there's some new AI buzzword I havent heard of, called (say) Customizable Intelligence and its like modular AI models and its the big new thing but I havent encountered it before, and people are calling it CI.

- ok so I could peruse the page and eventually figure out that they are talking about continuous integration rather than some other thing. Or I could google it. But why make me do detective work like that? To me not defining the acronyms makes it seem like the author is stuck in a little subculture and can't imagine anything outside of it. It kindof puts me off. You could think of it as the textual equivalent of a code smell. Its make me think they're just down a trendy jargon rabbithole and I've seen enough of those over the years. (I'm not saying they are in this case, just saying that to me the lack of definitions put me off)

But Ok as I said above this is perhaps something that the author never expected to reach such a wide audience so I'll shut up now. But in general I believe in defining acronyms. Because there's just too damn many of them.

hello! i am taking this as valuable feedback and would improve the website more! like you suspected, this is more of a project ive been building to solve problems ive been facing and didnt really do much publicity hence the website could definitely use some more love!

Agreed. I have no idea what this is after reading the front page.

I assume it's mainly targeted at devops people who absolutely know what CI/CD is and use it all the time.

Every person involved in software engineering should be aware of CI/CD and use it all the time, not only "devops people".

This case is a special though, as Bob CD is not a 100% complete package for doing CI/CD, it is one fundamental building piece for building your own CI/CD solution on top of.

So devops people would use Bob CD to build their in-house solution for it, and everyone would be using that, without actually using Bob CD directly.

Agreed. However, I still believe explaining acronyms is good practice.

I'm in software engineering and I'm aware of continuous integration but rarely use it and when I see CI its not the first thing that springs to mind. Any questions?

Every person who should be aware of CI/CD needs to learn it at some point.

For anything to do with embedded development, this is not reasonable.

Maybe try https://bobbuildtool.dev/ ?

Perhaps I should have been clearer.

Having an automated process to check out the most recent revision of the codebase and compiling it is just as easy as with other development.

Doing anything with that in an automated process is usually far more difficult. Suppose I'm developing a WiFi thermostat. The flashing process for that may require manual intervention, but let's leave that aside.

So the new code runs, now what? I need a webcam to look at the display, a robot to press the buttons or turn the wheel, and further fixtures to see if it is turning on the furnace appropriately.

Or we could simulate all the hardware in software... do I need to explain how much of a project that in itself is? Sure, it can be done, but it is the old question of time and cost.

I had thought this would be Microsoft Bob shipped on a CD-ROM ;)

Was mildly disappointed when I found out it had nothing to do with MS Bob, not going to lie.

What a strange and weirdly beautiful piece of misguided computing history.

Me too! What a 90's throwback.

Wasn't it shipped in a CD in the first place?

Yes! And the CD was entirely printed with Bob's yellow, smiling face.

I googled for a picture: https://ia800305.us.archive.org/12/items/microsoft-bob-v1_00...

That's why I clicked. Ah well.

Finally, we can use Bob to automate build of Vegana [0].

[0] http://biodiver.bio.ub.es/vegana/WhatsVegAna.htm

Finally a valid use case to request someone open them

No real critique against this project but where I work we have an in-house build system called Bob and I've heard several other companies that have systems named the same. The Bob the builder reference is too easy to pick up I guess.

We need to get more creative with our project names nowadays people. Things with too obvious references are usually not smart enough.

The use of XTDB and RabbitMQ is annoyingly overcomplicated. Why have a central database? Why not use a simpler more standard storage mechanism, or just pluggable storage for each component? Why not just use HTTP calls to static nodes instead of RabbitMQ?

I don't know much about RabbitMQ, but with XTDB, it basically runs in the application already (akin to sqlite) while using another DB engine for the actual storage. So with XTDB you can store things in memory, on disk via rocksdb, or JDBC connection (whatever that supports, MySQL, PostgreSQL and so on)

hello! the author here! the primary reason for going with this architecture is to make it scale well with off the shelf production ready tooling. RabbitMQ was chosen to provide a scalable durable queue for backpressure support and load balancing across runners, error handling etc. it adds onto the infra weight a bit but seems to be a simpler choice to program against and use libraries. The reasons for XTDB are mainly 2: it provides a temporal immutable store, hence the whole state of the CI system can immutably evolve like a git repo hence the whole thing can be inspected at a previous time. Bob treats time as a first class thing and not just build logs but you should be able to see the whole cluster at a past time and debug it fully as all of the state is the DB. The second reason is like @capableweb said, it decouples storage from compute so that we can have a pluggable storage and not a central point of compute.

> Everything should be made as simple as possible, but no simpler

I would rather have the hero text describe what the product is/does instead of it being an inspirational quote.

How does this compare with Concourse?

My question too! They say a goal is [1]:

> Be more extensible than great things like Concourse.ci

There's a "Bob vs the rest of the CI tools" section in the docs, but none of it really applies to Concourse.

[1] https://bob-cd.github.io/pages/why-bob.html

hello! the author here! this has been pretty much made with the intention of me trying to address some of the shortcomings i experienced in the kind of tooling ive used over the years as an infra/sre person. never made it with the intention of making it general enough tool for everyone but more as a manifestation of what i think tools could've been like. it draws a lot of inspiration from concourse but improves on aspects like decoupling the way one can describe things for instance in YAML like concourse, no central controller in the cluster and things like being designed for being cloud native upfront by having rootless unprivileged runners etc. the way i see it concourse is a production ready, general version of this and other people like the idea of bob, it could be too by evolving more on the ideas of concourse.

Reply on news.ycombinator.com