Re: Continuous Integration for KDB

[p.buko...@gmail.com]

tdd has nothing to do with programming language,
so there should be nothing to stop you from writing tests and then
some business logic.

There should be no problem to define few jobs in hudson to pull
changes from svn/git/etc. and run unit/integration/system tests on
*nix slave (no q version dep.).
If necessary wrap it around with make/ant/scons at any stage of your
job schedule.
I'd say imagination is the only show stopper ;-).

Cheers,
Patryk

sent from droid

On Oct 12, 9:31 am, Ajay <rathore.a...@gmail.com> wrote:
> Hi,
>
> Has anyone experience of using the modern day's continuous integration
> servers for CI and deployment of KDB processes. Like java developers
> can use to hudson, cruise.
>
> What strategy people use to perform test driven development with Q, i
> believe that 32-bit KDB version is the only option for running tests
> in a CI like environment.
>
> Ajay

[Attila Vrabecz]

i'm sure somebody from Kx will contact you
but i reckon that the trial license should not be used for anything like this
  Attila

On Fri, Oct 14, 2011 at 2:58 PM, Ajay <rathor...@gmail.com> wrote:
> Being able to program in four different languages, i am fully aware
> that tdd could be practiced anywhere.
>
> I think you missed the whole point, i know how to configure jobs in
> hudson to run distributed builds on remote machines.
>
> I was more interested in knowing about existing approaches used by
> people for configuring CI in their projects, weather they use free
> version of q for running their tests (which i believe wont work for
> load testing TP and RDB) or they have run their test suit on machines
> installed with licensed 64 bit q. What are the best practices used for
> CI in the context of KDB.
>
> Ajay
>
> On Oct 13, 2:28 pm, "P.Bukowin...@gmail.com" <p.bukowin...@gmail.com>

> --
> You received this message because you are subscribed to the Google Groups "Kdb+ Personal Developers" group.
> To post to this group, send email to personal...@googlegroups.com.
> To unsubscribe from this group, send email to personal-kdbpl...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/personal-kdbplus?hl=en.
>
>

[Tripathi, Rohit]

>weather they use free
>version of q for running their tests (which i believe wont work for
>load testing TP and RDB)

Wow

>What are the best practices used for CI in the context of KDB.

So here's the most useful answer I can provide in the context of the above: expect meltdowns :)

-----Original Message-----
From: personal...@googlegroups.com [mailto:personal...@googlegroups.com] On Behalf Of Ajay
Sent: Friday, October 14, 2011 7:29 PM
To: Kdb+ Personal Developers
Subject: [personal kdb+] Re: Continuous Integration for KDB

Being able to program in four different languages, i am fully aware
that tdd could be practiced anywhere.

I think you missed the whole point, i know how to configure jobs in
hudson to run distributed builds on remote machines.

I was more interested in knowing about existing approaches used by
people for configuring CI in their projects, weather they use free
version of q for running their tests (which i believe wont work for
load testing TP and RDB) or they have run their test suit on machines
installed with licensed 64 bit q. What are the best practices used for
CI in the context of KDB.

Ajay

On Oct 13, 2:28 pm, "P.Bukowin...@gmail.com" <p.bukowin...@gmail.com>
wrote:

--

You received this message because you are subscribed to the Google Groups "Kdb+ Personal Developers" group.
To post to this group, send email to personal...@googlegroups.com.
To unsubscribe from this group, send email to personal-kdbpl...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/personal-kdbplus?hl=en.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.

[David Roberts]

Write your tests in Q and commit them to sourcecontrol. 

Have the CI tool synchronize the sourcecontrol tree to your test server when needed. 

Have your CI tool execute the Q binary (licensed) and have your tests log something understandable to the CI tool.

Most CI tools are not much better than a cronned unix script doing the above and emailing any errors, though CI web interfaces are a slight improvement over email.

David

On Oct 15, 2011 1:24 PM, "Ajay" <rathor...@gmail.com> wrote:

Wow, that was really insightful...

On Oct 15, 1:38 pm, "Tripathi, Rohit" <rohit.tripa...@capgemini.com>

> For more options, visit this group athttp://groups.google.com/group/personal-kdbplus?hl=en.

[david tweed]

Without getting involved in any of the discussions in the thread,
there's a technical question related to this I'm interested in. Is
there a way to configure, either by command line or script, things so
that upon an error the Q interpreter doesn't break to the shell
prompt? (If I run a script containing an error, the process stops in
the interpreter.) When doing semi-automatic testing of code with a
multitude of options I don't really want to do that because:

1. Running all the tests might and knowing which ones fail might help
see the bug quicker than trying to debug the first failure in
isolation.

2. Even if I do want to debug the failing script, I generally want to
do it at a later time in more controlled circumstances.

Doing protected evaluation of a full script has the side effect of
meaning that "top-level code" setting global variables is no longer
top-level any more.

Is there a known solution to this problem,

Thanks, David

[Lukasz]

I use JUnit to run my unit tests, really handy when using Maven for
build management

For each q source file
1) create JUnit Test Case
2) from JUnit Test Case start q process (licensed) and load the q file
under the test (you can do it with Runtime.exec(command) )
3) Execute your test code. You can either call functions under the
test/assert results from JUnit @Test methods or if you have your tests
written in q just load them and execute

Put all test cases to src/test/java and they will run during maven-
test phase

Lukasz

On Oct 14, 2:58 pm, Ajay <rathore.a...@gmail.com> wrote:
> Being able to program in four different languages, i am fully aware
> that tdd could be practiced anywhere.
>
> I think you missed the whole point, i know how to configure jobs in
> hudson to run distributed builds on remote machines.
>
> I was more interested in knowing about existing approaches used by
> people for configuring CI in their projects, weather they use free
> version of q for running their tests (which i believe wont work for
> load testing TP and RDB) or they have run their test suit on machines
> installed with licensed 64 bit q. What are the best practices used for
> CI in the context of KDB.
>
> Ajay
>
> On Oct 13, 2:28 pm, "P.Bukowin...@gmail.com" <p.bukowin...@gmail.com>
> wrote:
>
>
>
>
>
>
>