[Cialug] Release Management

[c]

As Jim said. A lot of it is about the tools, but it depends on your
developers' process. If all of your developers have a full virtual
environment on their machine that is a clone of production, and they do all
development there, then you can use tools to keep your environments
separated.

Ideally your devs do all development on their local virtual machine.

- Once the Dev has a working fix they check all of that code into remote
git/ code versioning.

- Dev ties that commit into your ticketing system. Through the ticketing
system they note that the fix is ready for testing.

- QA  approves pushing the Devs changes to the QA/testing machines

- QA either approves fix, or sends back to Dev to update/fix per QA
comments.

- Once QA approves change, in the ticket and the system schedules the
automated push to production per your rules for regular or emergency
updates.

--Purcell

......
.

.
....
 On Aug 21, 2014 10:38 AM, "jim kraai" <jimgkraai at gmail.com> wrote:

> i've seen it all, i think
>
> isolation is good, if flushes out forgotten steps, assumptions, and
> configuration issues.
>
> a lot of times process comes from tools instead of the other way around
>
> jenkins is a good tool for what you've mentioned.  as little or as much of
> the business process of release management can be run from it and it can be
> a good reference for what's where
>
> --jim
>
>
>
> On Thu, Aug 21, 2014 at 10:12 AM, Todd Walton <tdwalton at gmail.com> wrote:
>
> > How many of you work at a company with a managed release process for
> code?
> > Like, you maintain identical dev/qa/prod servers, and developers write
> code
> > and get it working, then you release it to a testing environment and have
> > users break it, then production when it's ready, etc...  Do you have
> > something like that where you work?
> >
> > Where I work we're still sort of developing all that, but the basic
> outline
> > is like I've said above.  However, in the past, developers have typically
> > had access to not only the dev servers but also the testing servers.
> We're
> > now starting to limit that access, so that releasing to testing is just
> > like releasing to production, so you truly have a good test of whether
> the
> > code is good or not.
> >
> > I'm considering whether or not developers should be able to push their
> own
> > code to testing, but still restrict their access to the testing servers.
> > Like, some automated button they can push that takes dev and puts it in
> > qa/test, but they can't go and fiddle with server settings.
> >
> > --
> > Todd
> > _______________________________________________
> > Cialug mailing list
> > Cialug at cialug.org
> > http://cialug.org/mailman/listinfo/cialug
> >
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>