Absolutely disagree. Infact if you google ‘Continuous Deployment’ the first result (from Atlassian’s site) is:
Continuous Deployment (CD) is a software release process that uses automated testing to validate if changes to a codebase are correct and stable for immediate autonomous deployment to a production environment.
CI/CD is entirely reliant on automation to succees, otherwise it is just normal development with quick release cycles.
Usability testing is more of a general thing done a lot on an initial release and less on subsequent releases (only for new features/changes to functionality). It wouldn’t really fall under CI/CD, it would fall under UAT.
you can use automated testing and CI , and not have continuous deployment.
but indeed, continuous deployment, would generally require some level of automated testing.
ah, you see, thats the crux isn’t it - this has zero to do with continuous deployment…
primarily this is about development resources - and that comes down to priorities and focus.
the thing is, there is an overhead on things like continuous deployment, a cost.
so do you want those resources spent on that… or on something else… like development ?
obviously for companies pushing out lots of changes to lots of apps , it makes sense to automate this, as the ‘release process’ itself becomes expensive, and they have teams to manage just that.
but for smaller teams, this is not so much an issue.
you could argue, deployment to your website of firmware would count…
but for sure, its not really the meaning
partly because an important driver behind CD is to have users all on the latest and greatest (and the benefits that brings to support/maintenance) , so requiring an manual step - kind of defeats thats
@thetechnobear actually just realised I may have misinterpreted what you said. I took ‘continuous deployment’ to mean ‘what happens when the developers says they’re finished’ but in the context of this thread it’s more ‘making release cycles shorter’. If I’d used the latter context, I might not have made the long reply.
Yip, I only recently updated to Mojave and will probably only go to a newer version when I buy a new Mac. I hate the amount of things Apple breaks these days every year with the new macOS. And most of the time there is nothing new that I actually need or want.
Open source would be ideal, but I understand why it doesn’t happen. CD for firmware seems like a bad idea. Not because of quality, but because of the difficulty in rolling back when you ship actual software (rather than a service.)
To get past the problem you stated (just one more feature) rolling time boxed releases (like Ubuntu) would ensure that changes/fixes keep coming, but that we don’t wait for everything at once.
I also agree with Finn to some agree, ship a finished product. If firmware can extend life/fix bugs, great, but don’t ship a beta and patch it later.
It even has a section about CD (Cont. Deployment) vs. CD (Cont. Delivery) which I think is where we are all overlapping here.
As with all things related to software development though, it’s all open to interpreteation and remoulding to fit your team/company/way or working. That’s Agile.
I don’t want updates more quickly. Even in an ideal concept where they were bug free, I cannot keep fluid and retain muscle memory if things change too fast.
Opposed to it personally. By and large don’t agree with CI/CD. It has it’s uses, but when you are bragging about pushing updates/bug fixes every 7 minutes; that just screams to me that you have failed to properly mange your project, create milestones etc, and are quite happy to be constantly pushing changes at your user base.
CD “works” in some situations were, primarily SaaS et al where your core business drivers are quick-to-market, then traction, then market share; so you are constantly trying to “improve” and “extend” the core product (Bearing in mind that often times features are removed as well)
Maybe everyone just read The Lean Startup and are drinking that kool aid?
Open source your core IP? Think about that carefully for a moment.
I doubt all these modern software development methods like Agile, CD, CI, unit testing, etc. can be effectively used for Elektron firmware development.
Elektron firmware is written in assembly and the development environment is probably very special to fit in mainstream processes.
I am also sure customers rather want stable and solid releases less frequently than updates every week or month.
I don’t think “agile” suits hardware development at all. I suspect you get much better integration from longer term planning, when working on hardware. After a certain point, the hardware design is fixed, so you lose a huge amount of your agility.
If someone who does hardware for a living wants to school me otherwise, I’m all ears - it’s a career goal to spend some time (but not too long) as a scrum-master/coach.
