4 ms·

If you release only a month or 2 you are doing something really wrong (or need to work based on some insane spec). Read the basics about CI and CD, read the cl

by sydd 10y ago

If you release only a month or 2 you are doing something really wrong (or need to work based on some insane spec). Read the basics about CI and CD, read the clean code book, read about modern organisation practices (e.g. Github releases several times a day). Releasing every month or so is (thank God) a relic of the old waterfall development times.

rabidrat 10y ago
I would say this must be satire but you seem sincere. You are promoting a thin slice of modern "best practices" which are not the only way to do software development. And it doesn't sound like you've ever worked on a major software project if you think that a month is a prohibitively long development timeframe. A mid-size architectural refactor of a large codebase can and maybe should take a month. When you get into the 200k+ SLOC range, no one person understands the entire thing, and most of us don't want to 'move fast and break things' when a little forethought, communication, and analysis can avoid it. I think this 'growth at all costs mentality' is ruining a lot more than our software, too.
diek 10y ago
No, they're not. Is IntelliJ "doing it wrong" to release every three months[1] ? Absolutely not. A release can change things about a product, and you want to ensure you are pushing those changes (UI, behavior, plugin APIs) at a pace that matches the users. You don't want to be pushing changes to a plugin API every day. The surface area of stability that has to be maintained at that point is insane. In the interim, you should definitely be able to build off master. Your CICD server should build and run tests on every commit to master. Then a release gets a tag in version control and you should be able to issue bug fix releases for only that specific version. Telling customers, "There is a critical security bug in version X, but in order to fix that bug you need to upgrade completely to version X+2" is not an acceptable answer. Note that the description above works best in my experience for products that push a release artifact (like IntelliJ) versus a service like GitHub. Release management approaches will vary based on the product. [1] https://www.jetbrains.com/idea/download/previous.html https://www.jetbrains.com/idea/download/previous.html
alkonaut 10y ago
We do CI, not CD. Lots of software doesn't do CD and lots of it can't. Games. Embedded. Desktop. Store-apps. In my case it's large desktop software for structural engineering. Customers don't want new versions more than 1-2 times per year because of deployment, training and code compliance requirements. If we bork a release we have had users make a long download+install again. We don't just deploy the fixed one in prod to solve problems. Thats why a release goes through hundreds of hours of manual testing. Not to mention data: a feature is a new file format. If we ship one new feature we basically ship a new format. Now you know why Autocad, Word and Illustrator ships once per year and not once per commit. I think what a lot of people (who presumably do web dev only) forget is that web dev is just one of many software development disciplines, and a very young discipline too. I know of the practices you mention. I like clean code (both the book and the idea). I'd do CD if I had a project some day that runs on a server. I hope I won't have to do web dev any day soon though.
- sydd 10y ago
  You can do CD without releasing, its not pressing the release button that matters. CD means that you can press that button any time. Do small changes, test continuously, work on master. If you make small changes and test them (using automation - unit tests, integration tests etc) you are catching bugs early, avoiding merge conflict (the most evil operation of them all). This is not my idea, its in the clean code book and its the basic of the CI/CD/TDD disciple. And you can apply this to projects of all kind - we used it on the server, for iOS projects where we had to wait for Apple for weeks etc.
  - flukus 10y ago
    This is an important distinction. Another one is that just because you aren't deploying to production regularly doesn't mean you aren't deploying to other environments.

by sydd 10y ago

rabidrat 10y ago

I would say this must be satire but you seem sincere. You are promoting a thin slice of modern "best practices" which are not the only way to do software development. And it doesn't sound like you've ever worked on a major software project if you think that a month is a prohibitively long development timeframe. A mid-size architectural refactor of a large codebase can and maybe should take a month. When you get into the 200k+ SLOC range, no one person understands the entire thing, and most of us don't want to 'move fast and break things' when a little forethought, communication, and analysis can avoid it. I think this 'growth at all costs mentality' is ruining a lot more than our software, too.

diek 10y ago

No, they're not. Is IntelliJ "doing it wrong" to release every three months[1] ? Absolutely not. A release can change things about a product, and you want to ensure you are pushing those changes (UI, behavior, plugin APIs) at a pace that matches the users. You don't want to be pushing changes to a plugin API every day. The surface area of stability that has to be maintained at that point is insane. In the interim, you should definitely be able to build off master. Your CICD server should build and run tests on every commit to master. Then a release gets a tag in version control and you should be able to issue bug fix releases for only that specific version. Telling customers, "There is a critical security bug in version X, but in order to fix that bug you need to upgrade completely to version X+2" is not an acceptable answer. Note that the description above works best in my experience for products that push a release artifact (like IntelliJ) versus a service like GitHub. Release management approaches will vary based on the product. [1] https://www.jetbrains.com/idea/download/previous.html https://www.jetbrains.com/idea/download/previous.html

alkonaut 10y ago

We do CI, not CD. Lots of software doesn't do CD and lots of it can't. Games. Embedded. Desktop. Store-apps. In my case it's large desktop software for structural engineering. Customers don't want new versions more than 1-2 times per year because of deployment, training and code compliance requirements. If we bork a release we have had users make a long download+install again. We don't just deploy the fixed one in prod to solve problems. Thats why a release goes through hundreds of hours of manual testing. Not to mention data: a feature is a new file format. If we ship one new feature we basically ship a new format. Now you know why Autocad, Word and Illustrator ships once per year and not once per commit. I think what a lot of people (who presumably do web dev only) forget is that web dev is just one of many software development disciplines, and a very young discipline too. I know of the practices you mention. I like clean code (both the book and the idea). I'd do CD if I had a project some day that runs on a server. I hope I won't have to do web dev any day soon though.

sydd 10y ago
You can do CD without releasing, its not pressing the release button that matters. CD means that you can press that button any time. Do small changes, test continuously, work on master. If you make small changes and test them (using automation - unit tests, integration tests etc) you are catching bugs early, avoiding merge conflict (the most evil operation of them all). This is not my idea, its in the clean code book and its the basic of the CI/CD/TDD disciple. And you can apply this to projects of all kind - we used it on the server, for iOS projects where we had to wait for Apple for weeks etc.
- flukus 10y ago
  This is an important distinction. Another one is that just because you aren't deploying to production regularly doesn't mean you aren't deploying to other environments.