## page was renamed from Software/Development to TestSystem
Describes the CAcert software development process, from developer to test system to production system.

''This sounds very outdated to me, but may be interesting as a historical document... :-) BernhardFröhlich''

The email below is a starting point for this documentation.
Q: How does one get a testsystem account? 

{{{
> From: Philipp Guehring [mailto:philipp@cacert.org]
> Sent: Monday, September 07, 2009 4:13 PM
> To: cacert-devel@lists.cacert.org
> Subject: Re: Change text on the website
> 
> Hi,
> 
> > there are patches on test1 ... when they are tested by some guys, they
> > will checked into a VCS ... then the admin detects that there are
> > changes between test1 and www.cacert.org (WCO) ... what's the next step?
> 
> No, the process works differently.
> On the testsystems, we have a refresh procedure.
> You can trigger the refresh procedure by going to the directory
> /testsystem.skel and running ./update.sh
> The refresh procedure downloads the new tarball and the new SQL table
> structure definitions from the production system, and deploys
> everything, so that you have a clean testsystem again.
> The only things that are left on the testsystem afterwards are the data
> in the database (the database-structure is diffed and patched, the data
> itself stays in place), and a backup of the old website version.
> So your old patches can be found in the old website versions, which
> aren't active anymore, and you will have to redeploy patches you want to
> test again.
> 
> Since the refresh cleans away any patches, we usually avoid doing it
> while others are currently testing their patches, and wait for the
> patches to be fully tested, before we do the next refresh.
> 
> Additionally, we are using additional testsystems, so that developers
> can test independently.
> 
> > (a)	copy the file from test1 to WCO ... and loose the changes which had
> > been made to WCO since the last copy of sources to test1?
> 
> No, the patches/files are copied to a personal directory on the
> production system, reviewed there and deployed when everything is fine.
> Afterwards they are commited to the internal CVS, and from there, the
> tarball is being generated.
> 
> Evaldo is currently being tasked with researching a better version
> control system / change management system that would allow a better
> deployment process (and fulfills our security requirements).
> 
> > (b)	patch the sources from test1 with the ones from WCO?
> 
> No, the old sources are archived, and fresh sources are taken.
> 
> > okay ... guys ... WCO is a critical system ... both ways do NOT work
> ...
> 
> Yes, I agree.
> 
> > if (a) takes place ... this means the the patch inbetween was not
> > necessary ...
> >
> > if (b) takes place ... why had the patched been tested by several guys?
> > ... the test were useless ...
> 
> 
> > guys ... we're working on a critical system ... so every patch needs
> a
> > review of a second person (maybe more) ...
> 
> Sounds like you are applying for the job?
> 
> > ... and ... can you (or anybody else) explain, how the sources can be
> > checked out, patched and checked in to a VCS? ...
> 
> Someone was working on automatically importing the changes into a git
> repository, but I haven't heard anything about it lately.
> 
> > we @cacert want to use the power of open source development ... but all
> > we do is to say 'here is the tarball, get it, patch it ... and ...'
> >
> > ... yes ... and what comes after the 'and ...'?
> 
> The problem we have is that we see networked version control systems as
> a security risk that we want to avoid. There have been
> remote-code-execution exploits for CVS, Subersion, git, ... in the
> past,
> both against the servers and against the clients.
> I have not heard about a high-security version control system that was
> specifically designed and developed against remote-code-execution
> attacks yet.
> So we developed a version control architecture, where our production
> system does not run a networked version control client/server, but we
> are still having version histories and decentral version management
> tools available. The architecture consists of a local CVS installation
> on the production system that uses filesystem based repository, a tool
> to automatically extract a cleaned version of the repository as a
> tarball.
> 
> > guys ... this is no open development for an open-source-project ... it's
> > closed development for an open source project ...
> 
> Have you uploaded your patches to http://bugs.cacert.org/ yet, so that
> they are visible for reviewers?
> 
> 
> > okay ... this mail causes me to keep awake half an hour more ... but
> > hopefully it's worth ...
> 
> Yes, thanks for reminding me about a few things.
> 
> > ... i don't want to block cacert, work against cacert or do something
> > against cacert ...
> 
> > ... i want to bring cacert forward ... but sometimes there is the need
> > to criticize ... and if this does not work in personal mail of via
 voice
> > i use a cc-party ... or a mailing-list ... ;-)
> 
> Hmm, cacert-devel should be the right place for this, yes.
> 
> Best regards,
> Philipp Gühring
}}}

 * see also [[SubmitPatch|Submit Patch]]

----
CategorySoftware