jipiboily

It's fun and there is a lot of love.

Wow, 3 soon 4? Awesome and congrats on the new one!

I agree it's not more amazing than someone working anywhere else, but startups are often seen as non-sense as you need to work 80 hours a week to get shit done, we were trying to break that a bit and just tell "hey, it's possible, it's not that hard actually!" :)

Hey, I'm the dad from that blog post, feel free to ask questions :)

Awesome, thanks.

<3 self-promotion done right :)

Really, where is that mentioned?

What would be the TL;DR? (or TL;DListen?)

Will it be recorded so more than 99% of the people could also have some insights? :)

I see they have a domain too: https://usekite.com/.

The part I am interested in is the "automatically" part of the "How does it work?" paragraph.

This looks cool, at first. There is not enough information to know if it really is.

How does that work in real life? How do you provide those Docker containers? Just Dockerfiles?

Is it paid or open source? The domain suggest it is open source, but can't be found on your org.

It certainly looks cool, I just want to know more...so that I could know if I should be excited or not. Currently, I am more like "meh, maybe?"

My 2 cents :)

Humanity at its best!

<3

Thanks for the clarification!

My 2 cents here, but I think hosting fees will be higher with Jenkins than small CI plans...there are free offerings and even the paid one starts with pretty cheap prices that makes it hard for me to justify even an hour of work configuring a server for that. That said, I know this is not how everyone is thinking.

Yeah, that, too.

You also are running your tests in a different environment (diff machine) which could catch some bugs IMHO. In addition to that, having the CI server deploying for you also means you can have a very limited part of your team that have actual production rights.

I never had any good experience with Jenkins, Hudson before that or CruiseControl.net (yes, I automated .Net deployment with that, years ago!). This is why I prefer hosted CI that can scale and won't struggle under the load of a few builds. Circle CI in addition will run your specs in parallel. It is very unlikely that you can be faster than them, I think?

For GitHub PRs' status, I think it is useful when you do code review and just get from one PR to the other and you can see it's status quickly, it's a nice to have, but we were able to move fast before that feature dropped a couple of years ago.

It might be a matter of taste, but waiting for the whole suite to run sometime seems like a waste of time, I am most of the time running only the specs that I think could break, and I rarely see red builds on Circle CI.

My 2 cents :)

I think it's a hard question to answer as it could be so different depending on the project.

Ideally, your projects should be deployable independently from the other ones, to a certain extent. As an example, your API projects should get deployed, then the other ones using that API can be deployed later, be it a few minutes later or even days.

Hopefully I answer part of your question here?

For deployment, "it depends™" but you can certainly do whatever you need to do, always a matter of time and money! :) Your CI server could kick something on your servers. I encourage you to look at the hosted CIs and their documentation.

I use it for my open source projects, but I personally think coverage % is not worth much for private projects. First, coverage doesn't mean well covered, it just means the code is being run. For new comers, it could be confusing and I find it more dangerous than anything to introduce that principle to beginners. My 2 cents :)

Nice service though!

Actually, they had that plan for a few months I think, they just added continuous deployment for their free offering a few days ago I think?

As mentioned in the post, there are TONS of options, I just mentioned a few ones :)

JP, author of the post here - let me know if you have any additions / questions! :)

I never flushed migrations, maybe I should! Thanks for the comment. Food for thoughts :)

From what I understand/think, this is roughly:

Create a new table, add triggers from old table to new table (with new column(s)), copy data, once everything is copied, switch the tables

I mentioned that, and yes, it is known to work really well. Shopify is using it, so does GitHub as far as I know.

Thanks for sharing, didn't know about that one.

Depending on your framework and ORM and how its column cache is working, it sounds like a good solution too!

JP, author of the post here - let me know if you have any additions / questions!

That would explain why it's getting on HN today...for the nth time :)

Everytime I see one of those, I want to love them. Then I remember how hard it is for those tools to keep up with the OS features. Not being able to add or fix stuff because a new OS version is out and the tool is not up to date (yet) is a total deal breaker.

Been there, done that, bought the t-shirt.

I would love to be proven wrong though! ;)

Two things here: - the +1s show some level of interest, but enough to dive in the code, so it's half interesting, and half useless - also, once you've reached a certain number of +1s....well, it's just noise and annoying. 50 +1...500+1...

Finally, no more :+1:s when it's all that is being said by everyone, without much discussions...yay to less noise!

Flynn raised money, so I guess it could be considered as making money, too? :)