3 ms·

> Once you have a working pipeline in place, you can focus on the features Bullshit, its just another layer of complexity to be managed and that may fail. My g

by collyw 8y ago

> Once you have a working pipeline in place, you can focus on the features Bullshit, its just another layer of complexity to be managed and that may fail. My guess is that it will take more time maintaining it than it will save you in the majority of cases.

Aeolun 8y ago
Given how annoying it is to SSH to a server, check out the code, restart all the relevant services, I think there’s a definite plus to having my system do that for me.
m90 8y ago
> My guess is that it will take more time maintaining it than it will save you in the majority of cases. From my experience, this has almost never been the case. Exceptions were when there was infrastructure for the sake of infrastructure.
- afarrell 8y ago
  If a leader is worried about their organization having infra for the sake of infra, then they should also worry that their user-facing product has features for the sake of features—- features that complicate an interface and don’t help a user get their job done. The solution is PMs, UX designers, and engineers who know to ask “why?” when a project is proposed.
  - davidjnelson 8y ago
    That's a good point. Many things can be overengineered/overdone, including UX design.
scarface74 8y ago
If my pipeline fails, it’s likely because of a build issue. I have two types of pipelines both based on AWS: 1. Push code to Github -> AWS CodeBuild spins up a prebuilt or custom Docker container (on a server that I don’t have to manage) to build and run unit tests -> Code Deploy agent runs on EC2 instance that runs a script to deploy website. 2. Same as above but Code Deploy runs a CloudFormation template to deploy/update lambdas and other related resources. The only part of either process that requires me to maintain a server at all is the web server. It takes me about an hour to set up a new pipeline at the most. It’s basically modified a bunch of yaml/JSON files. It’s a one time setup that pays dividends through the whole process. I’ve also used hosted builds with Azure Devops before.

by collyw 8y ago

Aeolun 8y ago

Given how annoying it is to SSH to a server, check out the code, restart all the relevant services, I think there’s a definite plus to having my system do that for me.

m90 8y ago

> My guess is that it will take more time maintaining it than it will save you in the majority of cases. From my experience, this has almost never been the case. Exceptions were when there was infrastructure for the sake of infrastructure.

afarrell 8y ago
If a leader is worried about their organization having infra for the sake of infra, then they should also worry that their user-facing product has features for the sake of features—- features that complicate an interface and don’t help a user get their job done. The solution is PMs, UX designers, and engineers who know to ask “why?” when a project is proposed.
- davidjnelson 8y ago
  That's a good point. Many things can be overengineered/overdone, including UX design.

scarface74 8y ago

If my pipeline fails, it’s likely because of a build issue. I have two types of pipelines both based on AWS: 1. Push code to Github -> AWS CodeBuild spins up a prebuilt or custom Docker container (on a server that I don’t have to manage) to build and run unit tests -> Code Deploy agent runs on EC2 instance that runs a script to deploy website. 2. Same as above but Code Deploy runs a CloudFormation template to deploy/update lambdas and other related resources. The only part of either process that requires me to maintain a server at all is the web server. It takes me about an hour to set up a new pipeline at the most. It’s basically modified a bunch of yaml/JSON files. It’s a one time setup that pays dividends through the whole process. I’ve also used hosted builds with Azure Devops before.