4 ms·
It is quite weird that "Build" and "Unit Test" are part of the Deployment Pipeline. For me the Deployment Pipeline starts with the Acceptance Tests that ensure
by hourago 4y ago
It is quite weird that "Build" and "Unit Test" are part of the Deployment Pipeline.
For me the Deployment Pipeline starts with the Acceptance Tests that ensures business quality running over already created artifacts. There are advantages to this approach, as different deployment pipelines may be required to deploy to different platforms even if all artifacts are generated by one build pipeline.
AWS seems to mix the concepts of Build Pipeline with Deployment Pipeline.
Deployment has had historically a meaning in software development, I do not understand why to change it now.
- deleted 4y ago[deleted]
- borissk 4y ago>> AWS seems to mix the concepts of Build Pipeline with Deployment Pipeline. >> Deployment has had historically a meaning in software development, I do not understand why to change it now. Maybe because traditionally software shops would run a build server on premise, and a deployment on AWS. Now Amazon want's to move the build process on AWS as well - making them a little bit of extra money.
- klysm 4y agoIs that still a common practice? I figured most companies are running builds in their existing pipelines infrastructure which in my experience is usually GitHub/Travis/GitLab/Azure DevOps/CircleCI/etc.. and then moving it up into AWS
- hourago 4y ago> making them a little bit of extra money. That may be the reason. To create an article that looks like professional best practices but it is just an advertisement. Microsoft used to do a lot of that in its war against Open Source back in the day.
- bradknowles 4y agoSo, at Whole Foods, we made heavy use of CodeBuild and CodePipeline. But I also had experience at building and managing most of the Jenkins servers that we used to use before moving over to the native commercial AWS tooling. Conceptually, it's easy enough to put these two sets of components together in the same "pipeline" tool. You just have to make sure that all the right steps and components are available, and that they are properly used. If so, you can set things up so that all your code goes through multiple online checks when it gets uploaded to the repo, and you prevent the code from being able to be merged to "live" (or "head" or "master" or whatever you want to call it), unless all the checks have passed. Once all the checks have passed, your pipeline can proceed to push that to live (possible with a human approval required), then deploy that to beta, then gamma, then a canary "onebox" in one AZ in one region, and then finally into your first real multi-server production environment in one AZ in one region. Then you can chain on from there, with potential tests that have to be passed at each stage, and baking in periods that are required, and then on to the next stage with the next onebox in the next AZ in the next region. Rinse and repeat. Of course, you also need auto rollback processes, in case your deployments fail. And what happens if you need to rollback the rollbacks? Ad infinitum. To that level, it's all just logical extensions of the initial concepts.
- ProjectMoonShot 4y agoI believe it is due to the fact that they are building for multiple targets e.g. CPU architectures such as ARM and X86 etc.
- 8organicbits 4y agoThe repo describes this as "a CI/CD pipeline to build an application and deploy [...]". I don't think they are changing any meanings here.