3 ms·

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 b

by 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

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.