4 ms·

I seriously don't understand how anyone can use most of these CI solution. Here is what everyone should demand from a CI solution: * Actual code that specifie

by eddieh 8y ago

I seriously don't understand how anyone can use most of these CI solution. Here is what everyone should demand from a CI solution: * Actual code that specifies a pipeline (not a GUI/config-file/DSL) * Supports any SCM, workflow, build system, and language * Supports complex mixed-language, mixed-build-system projects * Doesn't make assumptions about project's structure and processes * Able to run locally (but scales to clusters, etc) * Written in a common scripting language * Completely end-to-end customizable in the scripting language it's written in The only one I know that fits is BuildBot, but practically nobody uses it. [edit: formatting]

scarface74 8y ago
Well if the whole world has a different perspective than you, have you thought that maybe their wants/needs are different?
- eddieh 8y ago
  Sure that could be the case, but I think most people that set up and use CI just pick Jenkins or whatever on a whim, then we all read about horror stories and bad experiences because the solution they picked is a square peg and they're forcing it in a round hole.
  - scarface74 8y ago
    Why do I need all of that bespoked complexity, my yml file is just there to tell the build system the scripts or shell commands I want to run - that are also in my git repo. Fundamentally, a CI system for a simple application just has to gather dependencies, build a package/run automated tests and store the artifact somewhere. A deployment system just has to copy the deployment package to a server/group of servers, and do some type of installation process based on an automatic (Dev/integration environment) or manual approval process (who ever is responsible for pushing to any other environment has to approve the release). There are a million ways to skin the cat but if your build process or deployment process is too complex, maybe it’s more of a question of the maturity of your framework or tooling. My build process for .Net web apps is: - nuget restore - msbuild - run nunit - zip artifacts based on version. My deployment process is - run a CloudFormation file to configure AWS resources - deploy code to a VM - run one or two commands to configure IIS or install a Windows service. - run a few AWS CLI commands to start autoscaling, reconfigure API gateway, etc. No build servers to maintain, just an agent running on the target VM for deployment and a slightly custom Docker image for builds. —- For Lambda functions and scripting languages it’s even simpler... Build: - import deprndencies - create zip file Deployment - run CloudFormation YML file to deploy lambda The CF file can be the deployment step. If I need some programmatic, I can create a custom lambda backed resource that is run when the CF file is run.

by eddieh 8y ago

scarface74 8y ago

Well if the whole world has a different perspective than you, have you thought that maybe their wants/needs are different?

eddieh 8y ago
Sure that could be the case, but I think most people that set up and use CI just pick Jenkins or whatever on a whim, then we all read about horror stories and bad experiences because the solution they picked is a square peg and they're forcing it in a round hole.
- scarface74 8y ago
  Why do I need all of that bespoked complexity, my yml file is just there to tell the build system the scripts or shell commands I want to run - that are also in my git repo. Fundamentally, a CI system for a simple application just has to gather dependencies, build a package/run automated tests and store the artifact somewhere. A deployment system just has to copy the deployment package to a server/group of servers, and do some type of installation process based on an automatic (Dev/integration environment) or manual approval process (who ever is responsible for pushing to any other environment has to approve the release). There are a million ways to skin the cat but if your build process or deployment process is too complex, maybe it’s more of a question of the maturity of your framework or tooling. My build process for .Net web apps is: - nuget restore - msbuild - run nunit - zip artifacts based on version. My deployment process is - run a CloudFormation file to configure AWS resources - deploy code to a VM - run one or two commands to configure IIS or install a Windows service. - run a few AWS CLI commands to start autoscaling, reconfigure API gateway, etc. No build servers to maintain, just an agent running on the target VM for deployment and a slightly custom Docker image for builds. —- For Lambda functions and scripting languages it’s even simpler... Build: - import deprndencies - create zip file Deployment - run CloudFormation YML file to deploy lambda The CF file can be the deployment step. If I need some programmatic, I can create a custom lambda backed resource that is run when the CF file is run.