On Wed, Feb 10, 2016 at 4:30 PM, Karanbir Singh <kbsingh at centos.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/02/16 07:29, Bamacharan Kundu wrote: > > Hi, > > > > Vaclav presented the build pipeline very nicely and this would > > take out lot of tension for building the code, checking the code > > standards and test cases from the developer. > > > > I would like to add few points on this. > > > > On Tue, Feb 9, 2016 at 8:08 PM, Vaclav Pavlin <vpavlin at redhat.com > > <mailto:vpavlin at redhat.com>> wrote: > > > > > > Hi all, > > > > As KB wrote, I brought up the idea of using OpenShift as a glue > > (i.e. workflow controller). The result can be found here: > > > > https://github.com/vpavlin/cccp-demo-openshift > > > > TL;DR: > > > > The repository contains OpenShift Template defining the workflow - > > build,test, delivery and (very poorly) implements the steps through > > Docker images (i.e. Dockerfiles and run scripts). > > > > The developer should do only git push to his VCS and this should > > trigger the build process in the pipeline. > > in an onprem story that would map well, but note that were aiming to > run a hosted service with a distinct UI ( even if the UI is no UI ) > Yes, now I got it. I had a thought to minimize the number of Dockerfiles, so that the user does not get confused of. > > > > > In this TDD process all the environments (including the build, > > test, delivery) would be created as a container and once the step > > is over it will destroy the environment. As output this will > > generate a application runtime along with the successfully built > > application code to registry. > > > > As you mentioned this would be tagged with test along with jenkins > > build id, so that developer or QA can trace for which commit this > > is built. > > > > Then for the next stages, successfully built image would be > > deployed to openshift instance to get through the test, delivery > > stages checking, along with the quality gates. > > > > all the stages should be linked to pipeline and should be easily > > re-producible so that any one can check or regenerate the issues > > instantly. > > add another dimension there - collection of related containers, ie. > the entire microservice should be reproduceable. > > This means system needs to maintain all the linking and volume sharing of the components. > > > > It's easily runnable in Vagrant with use of Project Atomic > > Developer Bundle. > > > > If you are interested in more info, I'd suggest to read the readme > > in the repo, I hope it summarizes it clearly. > > > > It's a very minimal demo, but I think it suggests the path, which > > could take us to the Unicorns land, quite well:). > > > > Let me know in case of any questions, suggestions or requests for > > guidance in case anybody decides to take this further. > > > > I would like to take this further, please let me know if my > > thought process is in the same line as yours or any changes, > > suggestions. > > we need to work through whats needed to now integrate with the > cccp-index content, and then map that back to deliverables. I had > asked Zeeshan to look at registry side for delivery space, unsure how > far he's gotten with that. I believe, I should look for integration with cccp-index content? Regards Bamacharan -- Bamacharan Kundu IRC Nick- bamachrn http://bamacharankundu.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160210/7cc5ff17/attachment-0008.html>