> but rather "don't learn something new" when your goal is to get a product out the door.
I don't agree at all, because that argument is a poorly put-together strawman.
No one ever had to choose between setting up a CICD pipeline and churn out features. Ever.
In fact, continuous deployment makes it possible for everyone to get features out if the door as fast as they possibly can, and ensure deployments are two-way door thing instead of a finicky one-way door pray-that-it-works event.
The door where features have go get through is not JIRA, but the prod environment. It's inconceivable how some people try to pretend that automating operations adds no value.
And hell, CICD nowadays is trivial. You know why? Because of tools like Kubernetes/Cloudformation/CDK/Ansible/etc.
There is a whole lot of time before your first customer where you don't need any of this. Getting a MVP out > getting your engineering shinies.
In my company I first had servers directly on a bare metal box, with half the infra running on my workstation, then moved everything to docker-compose, then kubernetes and now I'm getting ready to get my CICD pipelines.
> There is a whole lot of time before your first customer where you don't need any of this.
No, there really isn't. Customers want features, and they want it unrolled as fast as possible.
How do you provide that? By automating your delivery process. You don't treat your infrastructure as a pet, and all you need to do to get a feature to all customers, fully tested and verified it won't break your service, is to push a commit.
With modern CICD systems and a basic Kubernetes setup, you get a fully working continuous deployment pipeline from scratch in about 15 minutes. There is no excuse.
The blog post is bullshit from someone who has zero insight and no relevant experience.
(I am not commenting on the article, I am commenting on the comment thread)
> Customers want features, and they want it unrolled as fast as possible.
I am going to reiterate: There is a whole lot of time _before_ your first customer.
Now I agree with you, on my last job we had no CICD, no tests and no procedures when I joined and it is _hell_ to release anything. Writing tests and doing the infra candy improved our velocity, even though technically we were doing more work. But this was _with_ customers. If you don't have customers, they don't care about the features.
> I am going to reiterate: There is a whole lot of time _before_ your first customer.
So what? Don't you understand that this just renders your point even less defendable?
> But this was _with_ customers.
So what? Do you expect to get your code to work only in prod? Do you hope that all the bugs you're adding right now should just pile up into a big tangled and unmanageable mess until it becomes a problem? Are you even bothered by the fact that your last commit may or may not have screwed the entire project?
There is absolutely zero justification to not automate testing and delivery. Zero. There is not a single usecases where pushing half-baked crashers without any verification should be ok.
I don't agree at all, because that argument is a poorly put-together strawman.
No one ever had to choose between setting up a CICD pipeline and churn out features. Ever.
In fact, continuous deployment makes it possible for everyone to get features out if the door as fast as they possibly can, and ensure deployments are two-way door thing instead of a finicky one-way door pray-that-it-works event.
The door where features have go get through is not JIRA, but the prod environment. It's inconceivable how some people try to pretend that automating operations adds no value.
And hell, CICD nowadays is trivial. You know why? Because of tools like Kubernetes/Cloudformation/CDK/Ansible/etc.