projectatomic
Proposal: Document workflow for a developer for developing on OCP using CDK/ADB
Why? Because this subproject should be about more than shipping a bunch of components as a bundle - it should be about tying them together into a coherent workflow for the development of containerised services intended for eventual deployment on Atomic Host (and potentially other environments).
@ncoghlan Let me fix your #3 and then see if you still think "workflow" is the right word :)
I suspect that's going to depend significantly on how much scope creep you decide to let me get away with, as I have some expansive ideas :)
Hmm, after seeing the updated README, perhaps my "suggested workflow" idea should be a separate, documentation only project. So the bundle delivers a box of parts, and then a separate project called something like "Atomic Suggested Workflow" would describe one possible way of stringing them together into a cohesive developer experience.
Does that approach sound plausible to you?
As indicated by the title change, I realised this idea can likely be tackled within the context of the Developer Bundle by providing an example workflow that shows how to integrate an Atomic Developer Bundle based local development workflow with various CI systems and deployment environments to create an end-to-end code-creation -> production-deployment pipeline.
So it wouldn't even need to rise to the level of being a "Suggested" workflow - it could just be an example of how the bundle can be combined with a specific selection of other infrastructure management components (e.g. invoking Ansible from the Dockerfile to script container builds or from the Vagrantfile to script VM builds, accessing your local source repos we're you're modifying code, etc). Other folks would swap in whatever they're using (e.g. Salt, Chef, or Puppet instead of Ansible, drone.io instead of Jenkins for CI, etc) in place of what's used in the example workflow.
Revised the title again, as there's no need to restrict this to just one example workflow - we could have multiple examples, demonstrating integration with different systems. So you could have, for example:
- a "Gerrit review, Jenkins CI, Ansible CM, oVirt deployment" workflow
- a "Kallithea review, Buildbot CI, Salt CM, OpenStack deployment" workflow
- a "GitHub review, Travis CI, virtualenv CM, OpenShift Online deployment" workflow
and so-on and so forth. You wouldn't want to demonstrate every possible combination, but even just the three above examples would cover a lot of ground. Does that make sense?
Yeah, I think so. I can imagine a sub-dir (e.g. "Workflows") that describe how one might setup various development and production scenarios.
However, in some related work/thinking I have been doing, I would really like to see a concept of an "application definition" (perhaps implemented in Kubernetes) that would allow a project/application to describe, in a tooling consumable way, the various recommended "flows" for that application. More on that soon.
OK, something machine consumable aside, I'll start figuring out how the Project Atomic docs system works and where we might be able to slot something like this in.
Do we want to try to fit it in with the main Project Atomic docs at http://www.projectatomic.io/docs/? That's currently a fairly flat structure, so it would likely require some work on the docs generation tools to expand it to include additional docs from the developer bundle repo.
I'd be prepared to tackle proposing & implementing that if we decided it was the right way to go.
On further reflection, I'm back to thinking it makes the most sense to pursue this as a documentation-only effort, distinct from the developer bundle itself. I've started a project along those lines under my personal account at https://github.com/ncoghlan/atomic-workflow-gallery and will try to turn this into a more fully fledged idea there.
After I've iterated on the idea for a bit, and assuming I like the results, I'll look at pitching it back to the Project Atomic team for inclusion as part of the official docs.
@All the ecosystem has changed from the time the issue has been raised. I think goal of this task would be Document workflow for a developer for developing on OCP using CDK/ADB
@hferentschik this issue was updated today to reflect the current use-case, can you help provide more info about what is the workflow here so that we can create a doc for it? The goal is to share this content between ADB and CDK. We can either do a "recommended workflow" or an "example tutorial", depending on what can be used most effectively. WDYT? Thx
@hferentschik, adding a link to the respective downstream issue for more background: https://issues.jboss.org/browse/RHDEVDOCS-119
adding a link to the respective downstream issue for more background:
@rkratky ahh, thanks :-) I was lost a bit on what this is about. I think a lot is still in there air here on how production environments etc look like, but I think the CDK has very little bearing on how to get from local development to staging/production environment.
Effectively the CDK provides a way to develop the application locally, but then the developer would at some stage push (or better a pull request of a developer gets merged) into a blessed repo. From there a it could be the staging/production OpenShift environment which picks the change up, builds it for QE, does testing and finally puts it into a queue for approval for deployment for production. I see very little of the CDK as such here.
But I guess it makes sense to have a discussion around this.
@hferentschik, FWIW, this use case ("from CDK to prod.") is viewed as the most important for CDK by GSS. What needs to be documented here is the part that's between "I'm happy with what I have running on CDK" and some staging/production environment. The user story might be something like:
"As a developer, I want to take my proof-of-concept project from CDK to a staging environment, so that it can be deployed to production."