HN user
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.
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 :)
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-end-to-end-testing-with-docker/
Is this doing anything else than leveraging Docker multi layers caching?
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's always a way.
What about splitting it in smaller parts? And apply the CI process to each module?
Agree. CI=3-7 minutes. CD can be 30-60 if needed.
Agree. Some faulty commits may go through. But then you strengthen your test suite to prevent similar issues to happen again, and so on.
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 API. They all need to test their changes. Automatically if possible. Hosting external elements like the database and others is a pain eased by Docker.
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 and I've missed it? In which case I agree, custom code is not needed.
I didn't know about dotmess. I'll check it out. Thanks for the tip.
What tests are which kind depend on your use case. And is an infinite debate. I don't really care how you call them :)
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"
Ok thanks. Won't post articles as Show HN in the future.
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 "rejected and we scrap it all out". At the end of the day the number of feature toggles should remain relatively low.
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!
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?
Flipt is an interesting concept! I've tracked you down on Twitter. Let's talk when you have time ;)
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 right way. Mistakes and errors should be caught by the CI build.
Getting from here to there probably requires a transition phase. In the long run though, if the time spared/lost waiting for PRs, developers context switching, resolving conflicts and dealing with errors (that will appear anyway) is invested into improving the quality and speed of automated tests, you end up in a much better place.
I'm not saying it's an easy thing, but in my opinion this is what development teams should strive for.
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 waiting for code review).
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 * By the time PR3 build is finished and green, head of main branch is commit N+2. So it's not safe to merge * A new build is automatically started for the merge of PR3 and main branch commit N+2. If it's green, it is merged, created main branch commit N+3.
See what I mean? (and obviously I can't figure out how to make bullets in this editor sorry ...)
With a build lasting 30 minutes, cases like PR3 above are more likely to happen. But then it doesn't really matter: the build tool will just run builds until it merges. The real issue here is the delayed feedback for the developers: if you are interrupted every 30 minutes with some build status (green or red), it's quite a waste of time daily in terms of context switching.
What CI tool and Git provider are you using? Lately I've worked with a team with a build of 28 minutes using TFS VSTS. We got the build down under 10 minutes using conditional builds (tests ran only if some folders have changed).
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 than 2 builds each time (or you have a huuuuge team working on the repo).
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 take more than 2 builds each time (or you have a huuuuge team working on the repo). What do you think?
A) Yes. If you have multi steps // builds the steps can be distributed amongst your team so it goes faster.
B) Yes. You can choose to run only your builds on your machine.
Much appreciated!
Thanks man! Reach out if you need any help or have any questions!