6 ms·

You stopped at the first sentence? Sheesh... You missed all the context. I read the link and it does indeed explain how his project failed because he wasn't co

You stopped at the first sentence? Sheesh... You missed all the context. I read the link and it does indeed explain how his project failed because he wasn't continuously integrating his code in to the main branch. It's not just about CI, but actually _continuously_ integrating code.

Clubber 9y ago
Then it should be, "Our project failed because we hired developers who didn't know how to use source control in a team environment, we never noticed, and we never established processes or expectations." CI is more than just source control, it's ticketing and associating tickets with branches, and automated deployment, automated unit testing, yadda yadda.
- nulagrithom 9y ago
  https://en.wikipedia.org/wiki/Continuous_integration https://en.wikipedia.org/wiki/Continuous_integration
  - Clubber 9y ago
    You should read it. Of the 10 best practices in that article, three deal with committing. 4.1 Maintain a code repository 4.4 Everyone commits to the baseline every day 4.5 Every commit (to baseline) should be built It also includes the things I mentioned and a few others. 4.2 Automate the build 4.3 Make the build self-testing 4.6 Keep the build fast 4.7 Test in a clone of the production environment 4.8 Make it easy to get the latest deliverables 4.9 Everyone can see the results of the latest build 4.10 Automate deployment What was your point of linking that article? Are you agreeing that their problem was with source control and not that they didn't implement CI? Source control predates CI by quite a while.
    - nulagrithom 9y ago
      First sentence of the article: In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day. Guy didn't do that. His project blew up. He failed the basic premise of CI, and his project blew up. I'm not sure how much more clear it can be: his project failed because he didn't do continuous integration. He _did_ use version, as did everyone else in the company. But he didn't do continuous integration. And his project blew up. Ergo, the statement that caused you to immediately stop reading: "The post describes how a 6 months project failed because it didn't implement the principles of Continuous Integration."
      - Clubber 9y ago
        Yes, but CI is way more than just merging and source control, that's just the source control part. That part predates CI by 10 years. You can have source control and merging without CI. I'm reading from you that you are saying that if you merge branches you are implementing CI. There is a lot more to it. It's in the article you linked. He failed at source control (and really management processes) not because he didn't implement CI as claimed.
        nulagrithom 9y ago
        I don't know why I'm indulging your pedantry, and I think I'll stop after this, but what I'm reading from you is the following: Because he only failed at continuously merging his code and writing tests, but didn't explicitly mention that there was no build server, then he didn't fail at continuous integration. He only failed at version control despite the fact that they were using CVS, were branching and merging appropriately, but were not doing so in the rapid fashion that became prevalent 10 years after version control. Additionally, because projects have managed to succeed without continuous integration at all, the rest of the original article that simply mentions his "questionable" CI failure is not even worth reading (but is certainly worth commenting on). Disregarding how closed-minded it is to dismiss both articles based on that single sentence, by implementing proper CI he would've covered all these "version control" issues anyway. I think it's fair to call that a CI failure, as it does fall under the blanket of good CI practices. Secondly, I think your bar for "success" is too low if you're willing to throw out "ticketing, automated deployment, and automated unit testing" but still call a project a success. I'd call that an inevitable clusterfuck regardless of how well it runs at the moment. Without these CI basics it's going to suck to maintain that system in just a few short years. I really, really hate dealing with systems that were built without these should-be-obvious basics.

Clubber 9y ago

Then it should be, "Our project failed because we hired developers who didn't know how to use source control in a team environment, we never noticed, and we never established processes or expectations." CI is more than just source control, it's ticketing and associating tickets with branches, and automated deployment, automated unit testing, yadda yadda.

nulagrithom 9y ago
https://en.wikipedia.org/wiki/Continuous_integration https://en.wikipedia.org/wiki/Continuous_integration
- Clubber 9y ago
  You should read it. Of the 10 best practices in that article, three deal with committing. 4.1 Maintain a code repository 4.4 Everyone commits to the baseline every day 4.5 Every commit (to baseline) should be built It also includes the things I mentioned and a few others. 4.2 Automate the build 4.3 Make the build self-testing 4.6 Keep the build fast 4.7 Test in a clone of the production environment 4.8 Make it easy to get the latest deliverables 4.9 Everyone can see the results of the latest build 4.10 Automate deployment What was your point of linking that article? Are you agreeing that their problem was with source control and not that they didn't implement CI? Source control predates CI by quite a while.
  - nulagrithom 9y ago
    First sentence of the article: In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day. Guy didn't do that. His project blew up. He failed the basic premise of CI, and his project blew up. I'm not sure how much more clear it can be: his project failed because he didn't do continuous integration. He _did_ use version, as did everyone else in the company. But he didn't do continuous integration. And his project blew up. Ergo, the statement that caused you to immediately stop reading: "The post describes how a 6 months project failed because it didn't implement the principles of Continuous Integration."
    - Clubber 9y ago
      Yes, but CI is way more than just merging and source control, that's just the source control part. That part predates CI by 10 years. You can have source control and merging without CI. I'm reading from you that you are saying that if you merge branches you are implementing CI. There is a lot more to it. It's in the article you linked. He failed at source control (and really management processes) not because he didn't implement CI as claimed.
      - nulagrithom 9y ago
        I don't know why I'm indulging your pedantry, and I think I'll stop after this, but what I'm reading from you is the following: Because he only failed at continuously merging his code and writing tests, but didn't explicitly mention that there was no build server, then he didn't fail at continuous integration. He only failed at version control despite the fact that they were using CVS, were branching and merging appropriately, but were not doing so in the rapid fashion that became prevalent 10 years after version control. Additionally, because projects have managed to succeed without continuous integration at all, the rest of the original article that simply mentions his "questionable" CI failure is not even worth reading (but is certainly worth commenting on). Disregarding how closed-minded it is to dismiss both articles based on that single sentence, by implementing proper CI he would've covered all these "version control" issues anyway. I think it's fair to call that a CI failure, as it does fall under the blanket of good CI practices. Secondly, I think your bar for "success" is too low if you're willing to throw out "ticketing, automated deployment, and automated unit testing" but still call a project a success. I'd call that an inevitable clusterfuck regardless of how well it runs at the moment. Without these CI basics it's going to suck to maintain that system in just a few short years. I really, really hate dealing with systems that were built without these should-be-obvious basics.