jpdel

8 ms·

1.
The Hero Developer (who knew how to build Lego bricks)(fire.ci)
1 points by jpdel 7y ago|0 comments
2.
End to End Testing with Selenium in Docker(fire.ci)
2 points by jpdel 7y ago|0 comments
3.
by jpdel 7y ago
Also using Azure DevOps and it is indeed very well structured. As for CI/CD differences: how many commits can actually affect code and infrastructure? I think this is part of the engineering problem at the end of the day.
4.
by jpdel 7y ago
I think this is a business trend unfortunately. Tools tackling the CI space wanted a piece of CD and then boom. Things became the same :)
5.
by jpdel 7y ago
Agree. I would definitely put any infrastructure thing on the CD side though, as it is longer indeed. You can test your software faster in CI using Docker compose. Something along these lines: https://fire.ci/blog/api-e
6.
by jpdel 7y ago
Is this doing anything else than leveraging Docker multi layers caching?
7.
by jpdel 7y ago
We have a large Java monolith application. Builds ran for 30 minutes. Then we said let's only run the unit tests and critical smoke tests. The build time went down to 7 minutes ... on 12 CPU and 32 GB of RAM build slaves :) There'
8.
by jpdel 7y ago
What about splitting it in smaller parts? And apply the CI process to each module?
9.
by jpdel 7y ago
Agree. CI=3-7 minutes. CD can be 30-60 if needed.
10.
by jpdel 7y ago
Agree. Some faulty commits may go through. But then you strengthen your test suite to prevent similar issues to happen again, and so on.
11.
The Difference Between CI and CD(fire.ci)
194 points by jpdel 7y ago|58 comments
12.
by jpdel 7y ago
> There's no need to as I mentioned that you're going to be hosting it somewhere during development anyway. You will probably host 1 version which is infrastructure heavy and not very flexible. Take 10 developers working on the
13.
by jpdel 7y ago
nock will intercept http requests in the same node process it is used in. Here the test (and the mock) are in a different container and thus process. It won't catch them. Unless it is possible to actually spin up a server using nock an
14.
by jpdel 7y ago
I didn't know about dotmess. I'll check it out. Thanks for the tip.
15.
by jpdel 7y ago
What tests are which kind depend on your use case. And is an infinite debate. I don't really care how you call them :)
16.
API end to end testing with Docker(fire.ci)
95 points by jpdel 7y ago|27 comments
17.
by jpdel 7y ago
I've updated the sentence with "Here are the common objections one might have and a tentative solution" and extended the conclusion to say "TBD is not the only way to work"
18.
by jpdel 7y ago
Ok thanks. Won't post articles as Show HN in the future.
19.
by jpdel 7y ago
Agree that feature flags count should not explode because you can never test all combinations. Feature toggles should drive the life span of a feature from start of development to "adopted and becomes the default" or "rejecte
20.
by jpdel 7y ago
Fair enough. You have a valid point on "your objections are not valid" is not the right tone. I'll edit to highlight that feature branches have their benefits in some cases. Thanks for reading!
21.
by jpdel 7y ago
Not sure how the title is provocative? Even less click baity. And is there a rule I am not aware of against submitting my own posts?
22.
Show HN: Why you should not use feature branches(fire.ci)
13 points by jpdel 7y ago|44 comments
23.
by jpdel 7y ago
Flipt is an interesting concept! I've tracked you down on Twitter. Let's talk when you have time ;)
24.
by jpdel 7y ago
k8s is open source, which is a different setup: you can't just merge in anything that comes in. In commercial projects though, even with a large team, you should be able to trust any team member to contribute to the main branch in the
25.
by jpdel 7y ago
And now that I look at your question again: yes. If all 23 builds were green and one person merges, then it would trigger a build on the remaining 22. The thing being that you probably shouldn't have 23 PRs lying around (probably waiti
26.
by jpdel 7y ago
Nope. * PR1 is merged with main branch commit N: build OK. PR1 is merged creating main branch commit N+1 * PR2 is merged the same way creating commit N+2 * PR3 build started at the same time as PR2 build, so using main branch commit N+1 * B
27.
by jpdel 7y ago
See my comment above: a cool feature I am implementing into fire.ci now is that it will trigger a new build every time the main branch moves forward until the safe merge happens. If you have fast builds I don't expect this to take more
28.
by jpdel 7y ago
4th step should not happen. A cool feature I am implementing into fire.ci now is that it will trigger a new build every time the main branch moves forward until the safe merge happens. If you have fast builds I don't expect this to tak
29.
How do you generate release notes?
1 points by jpdel 7y ago|1 comments
30.
Show HN: How to Get Started with Continuous Integration(fire.ci)
49 points by jpdel 7y ago|22 comments

More ›