dev.fedoraproject.org

[Mike McGrath]

On Sun, 18 Jul 2010, Stephen John Smoogen wrote:

> On Sat, Jul 17, 2010 at 22:28, Mike McGrath <mmcgrath at redhat.com> wrote:
> > So it is probably time to have a dev.fedoraproject.org.  Why?  Well,
> > toshio had mentioned having others do some of the 'sysadminy' tasks so
> > developers can focus on development.
> >
> > Also Luke had an analogous request wrt community and staging but before I
> > go setting things up some topics for discussion:
> >
> > 1) Security staging and production are identical.  Since production data
> > regularly gets migrated to staging people that have access to one, might
> > as well have access to the other.  Generally our staging environment is
> > mostly used for integration work, some load work as well.
> >
> > 2) Should we run development from rpms that get edited (like live patches)
> > or should we run them from scm(ish) checkouts.  I generally vote for the
> > latter as it feels more useful in a development lifecycle.  But we should
> > come up with a quick standard for how to store this stuff.  something like
> > /srv/dev/
> >
> > 3) I don't want this to be all fancy.  All of our apps run in their own
> > namespaces so we should be able to get by with one or two app dev servers
> > and we should be able to use them without a reverse proxy.
> >
> > Questions comments?  It'd be nice to just throw them all together on a
> > couple of hosts in their own namespace.  It'll help find issues with them
> > playing together.
>
> I was wondering how our developer workflow would go for the publictest
> boxes.. people are using them for development and I wonder what stage
> of work we want things to move projects from one set to another.
>
> Scratch development: publictestXX.fedoraproject.org
> Integration development: XX.dev.fedoraproject.org
> Staging/QA: XX.stg.fedoraproject.org
> Production XX.fedoraproject.org
>
> So for the insight project. Work would go on
> publictestXX.fedoraproject.org.. and when it was ready to look at for
> production we would move it to say staging or dev? When it was ready
> for staging we would lock it down and move it to that git tree and
> push it out to see how it works in a 'real' environment. After it was
> finally tested there we would move to production?
>
> That is the initial picture in my head.. I just want to see if it is accurate.
>

I think you and I are thinking more or less along the same lines except I
might define it more that publictest is more for proof of concept and the
dev environments are more for collaborative development.  So there
wouldn't have to be a specific workflow from one to the other.  I'd
imagine now that pkgdb, community, fas, etc are all accepted projects that
the would likely not be on a pt host anymore except for say, someone shows
up and wants to make a drastic change to one?

Another example, stuff that we write that's already in our environment
would probably all be worked on from the dev servers.  Trac though,
probably not since we don't actually do coding with that.  We'd probably
use a pt server as a proof of concept to show that the new version works
with RHEL6, then come up with a migration plan for hosted2 and ultimately
hosted1 (where hosted2 serves as a staging environment in that case)

But really people come by a lot for proof of concept things and more and
more those things are kind of conflicting with the actual "code, test
commit" development work that I think most would agree need to happen.

Side note: there's over 100 accounts on the pt hosts now, we should
probably look into doing a sysadmin-test pruning soon.

	-Mike