Any feedback?
Does this silence mean everything is all right? :)
Seriously, we're jealously awaiting to hear from you on how it's going.
Whether it's good or bad please don't be silent!
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Please sign in to leave a comment.
I'm waiting for something that will allow our developers across 3 sites
to collaborate other than by telephone. A build server is only of
passing interest to me. (A full rebuild of our project only takes about
5 minutes on our dev machines.)
R
BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maxim Shafirov (JetBrains) wrote:
I just recently installed the EAP, but really had not enough time to
test it. Sorry. =)
Anyway, I want to know if MSBuild solution and projects are supported
already, or if they are planned to be supported. I know I probably can
find some tool to convert the solution and projects to NAnt, but will
probably want something more tightly integrated.
Regards,
Pablo
-
BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
iD8DBQFEHqNbvooSiBfQCSoRAsxpAKCAyLWeOE0YAcjhW5LcFl0QNAHpgACgwm6+
sfieHXNshw7lvqWN/cTuZ5k=
=Ut6N
-
END PGP SIGNATURE-----
I just installed the Build Server, but didn't have time to actually use
it yet. However since you are anxious for feed back, here is some web
interface stuff:
1:
The bottom "remove" link in the build queue sometimes jumps to the
"Build Type" column (see attached screen shot). This happens on Opera
8.51 on mousing over the link. If I first mouse over the link in the row
above and then over the bottom link, this behavior doesn't happen.
2:
In Internet Explorer the two columns don't line up (see attached screen
shot number 2).
Bas
Attachment(s):
build_queue_opera.png
build_servers_columns_ie.png
Hello Pablo,
Yes, MSBuild integration is planned for version 1.0 with no particular timeframe
though.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Hello Pablo,
You may watch http://www.jetbrains.net/jira/browse/TW-189 to be notified
when MSBuild capable agents are implemented.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Hello Robert,
RG> I'm waiting for something that will allow our developers across 3 sites
RG> to collaborate other than by telephone. A build server is only of
RG> passing interest to me. (A full rebuild of our project only takes about
RG> 5 minutes on our dev machines.)
The build server is not a tool for speeding up full rebuild. It's about completely
different things: knowing that your code always compiles, tests always pass
for the code, and so on.
http://www.martinfowler.com/articles/continuousIntegration.html
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maxim Shafirov (JetBrains) wrote:
Great!
Thanks,
Pablo
-
BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
iD8DBQFEHtFcvooSiBfQCSoRAob2AJwNhUIvCxnCcstTA/AwLq6pv4/J8ACghMd9
PF5iMGrcR63kv/ue4TfLnl4=
=B+6D
-
END PGP SIGNATURE-----
Will the server be able to modify files as part of the check-in process? So, the process "pass build/pass validation/check-in" could instead be "pass build/pass validation/perform transformations/check-in".
Hello Jon,
Changes will be commited by the IDE, not buildserver. Otherwise we'll get
into troubles merging files commited by server and actual changes at client
side. Having said that it doesn't seem impossible to perform additional transformation
from within IDE before real commit.
BTW, what use case you have in mind here?
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
We'll put TeamWare to work on a production project and give you detailed feedback the moment you push out a build with Maven 2 support....like other folks, we eagerly await resolution of http://www.jetbrains.net/jira/browse/TW-108
Thanks,
Jon
Maxim,
The use case I have in mind is enforcing a code style policy at commit time so that all code committed has a uniform code style (whitespacing, alignment, wrapping, etc.). I understand what you mean about needing the actual commit and changes to occur at the client side to create correct repository logs. It would be fine if that were applied back at the IDE, but the problem is enforcement. Perhaps the server can run the code style and reject the commit if running the style against the code introduces any change?
Once the server enforcement is in place, the next helpful feature would be to have the IDE apply the user's personal code style (possibly different than the company policy code style) as the code is brought down from the server. That way the developer can always see code the way they want to but the server always has the code in the company code style policy. Combining these two features-- which TeamWare seems ideally suited to do--allows a consistent repository free of code style variations yet permits individual developers to see the code on their machine in any style they prefer. The code format debates & wars become a thing of the past once and for all.
Jon
Hello Dmitry,
Probably it depends on a project. For example in our project we have several
source folders (main/mock/junit/fit) and we have several tasks besides compiling
(check jsp/code analyzing/run test(s)/run fit(s)).
Build process could be spitted between several agents. This is my vision:
-1-cycle----
agent#1 – compile main source folder
-2-cycle----
agent#1 – compile mock
agent#2 – check jsp
agent#3 – code analyzing
-3-cycle----
agent#1 – compile junit
agent#2 – compile fit
-4-cycle----
agent#1 – run test(s)
agent#2 – run fit(s)
Would be possible to split build process of a project in such way using TeamServer?
Best regards,
Alexander
RG>> I'm waiting for something that will allow our developers across 3
RG>> sites to collaborate other than by telephone. A build server is
RG>> only of passing interest to me. (A full rebuild of our project
RG>> only takes about 5 minutes on our dev machines.)
RG>>
Hello Alexander,
At the moment, splitting different phases of a single build between multiple
agents is not a supported scenario. I think you can set up something like
this manually (define different build types for different phases of the build
and have one of the build types explicitly wait for all others to complete),
but this would be quite tricky.
AC> Probably it depends on a project. For example in our project we have
AC> several
AC> source folders (main/mock/junit/fit) and we have several tasks
AC> besides compiling
AC> (check jsp/code analyzing/run test(s)/run fit(s)).
AC> Build process could be spitted between several agents. This is my
AC> vision:
AC> -1-cycle----
AC> agent#1 - compile main source folder
AC> -2-cycle----
AC> agent#1 - compile mock
AC> agent#2 - check jsp
AC> agent#3 - code analyzing
AC> -3-cycle----
AC> agent#1 - compile junit
AC> agent#2 - compile fit
AC> -4-cycle----
AC> agent#1 - run test(s)
AC> agent#2 - run fit(s)
AC> Would be possible to split build process of a project in such way
AC> using TeamServer?
AC>
AC> Best regards,
AC> Alexander
>> Hello Robert,
>>
RG>>> I'm waiting for something that will allow our developers across 3
RG>>> sites to collaborate other than by telephone. A build server is
RG>>> only of passing interest to me. (A full rebuild of our project
RG>>> only takes about 5 minutes on our dev machines.)
RG>>>
>> The build server is not a tool for speeding up full rebuild. It's
>> about completely different things: knowing that your code always
>> compiles, tests always pass for the code, and so on.
>>
>> http://www.martinfowler.com/articles/continuousIntegration.html
>>
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Maxim Shafirov (JetBrains) napisa?(a):
One thing that I found a little bit strange, although it doesn't hurt is that it seems that Builder Agent
uses PicoContainer, and main Team Server uses Spring for dependency injection. Wouldn't be just easier to
stick to one (whichever it would be) depencency injection container?
Michal.
Try to understand that I really don't mean to be an ass about this, but I'll start using the Team Server EAP once you've got a decent installer. It's a bit much to expect people to do a multi-stage install in order to test your product. It's way over the top to require people to install and configure another product (a J2EE container) in order to test yours.
In short, you lost me at "copy the war".
--Dave Griffith
Dave has a valid point. If the installation was easier, more feedback
would probably already have arrived.
A standalone mode would be nice to have (using Jetty perhaps).
Especially in those cases where the Build Agent runs on the same system
as the Team Server, this would be an quick way to get started. Even
better if the standalone mode included a default registered build agent.
Bas
Dave Griffith wrote:
+A standalone mode would be nice to have (using Jetty perhaps).
Especially in those cases where the Build Agent runs on the same system
as the Team Server, this would be an quick way to get started. Even
better if the standalone mode included a default registered build agent.+
I'd describe it more a "essential" rather than "would be nice to have". I'm a Java developer. System administration is something that happens to other people.
--Dave Griffith
Dave Griffith wrote:
I have created a JIRA item for it:
http://www.jetbrains.net/jira/browse/TW-190
Bas
Bas Leijdekkers wrote:
>> +A standalone mode would be nice to have (using Jetty perhaps).
>> Especially in those cases where the Build Agent runs on the same
>> system as the Team Server, this would be an quick way to get started.
>> Even better if the standalone mode included a default registered
>> build agent.+
>>
>> I'd describe it more a "essential" rather than "would be nice to
>> have". I'm a Java developer. System administration is something
>> that happens to other people.
The latest EAP (just uploaded) contains a distro with tomcat (but
without pre-installed agent, so the request isn't closed yet).
http://www.jetbrains.net/confluence/display/TW/Download
Kind regards,
KIR
--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
How about choosing a different port, for example 8111?
8000 is pretty much in demand: My Oracle installation uses the port.
Many developers will also use 8000 for their own development.
Kirill Maximov (JetBrains) wrote:
>>
>>
>> Dave Griffith wrote:
>>> +A standalone mode would be nice to have (using Jetty perhaps).
>>> Especially in those cases where the Build Agent runs on the same
>>> system as the Team Server, this would be an quick way to get started.
>>> Even better if the standalone mode included a default registered
>>> build agent.+
>>>
>>> I'd describe it more a "essential" rather than "would be nice to
>>> have". I'm a Java developer. System administration is something
>>> that happens to other people.
>>
>> I have created a JIRA item for it:
>> http://www.jetbrains.net/jira/browse/TW-190
Maxim Shafirov (JetBrains) wrote:
I couldn't have said it better, Maxim ;)
Seriously now, I've made the Team Server check-out and successfully build a more or less
simple project. Not a bad start actually. However, there are some things I haven't figured
out yet:
- How to check out specific branches from CVS? Branches/tags are not mangled into the
cvsroot like SVN does it, so I guess there has to be some CVS-related parameter I haven't
found yet.
- What's "checkout-on-server"?
- Is it possible to specify project dependencies? Say I've got some projects P1, P2 and P3
where P2 depends on P1 and P3 depends on P2 (and P1). P1 and P2 are "utility" projects
that are actually used in several other projects but are also developed and used
standalone. The P3 build is incredibly slow and I'd like this build to depend on the
results of P1 and P2 so that it doesn't even attempt a build if something fails here.
- The "Compatible Agents" tab looks a bit boring. Some details about each agent would be
nice (Java Version, OS type, System-Properties, Env, etc.) and maybe some statistics.
Sascha
Stephen Kelvin wrote:
OK, it's always a hard task to choose a port :)
8111 sound good. Will use it in the next EAP.
>> Bas Leijdekkers wrote:
>>>
>>>
>>> Dave Griffith wrote:
>>>> +A standalone mode would be nice to have (using Jetty perhaps).
>>>> Especially in those cases where the Build Agent runs on the same
>>>> system as the Team Server, this would be an quick way to get started.
>>>> Even better if the standalone mode included a default registered
>>>> build agent.+
>>>>
>>>> I'd describe it more a "essential" rather than "would be nice to
>>>> have". I'm a Java developer. System administration is something
>>>> that happens to other people.
>>>
>>> I have created a JIRA item for it:
>>> http://www.jetbrains.net/jira/browse/TW-190
>>
>> The latest EAP (just uploaded) contains a distro with tomcat (but
>> without pre-installed agent, so the request isn't closed yet).
>>
>> http://www.jetbrains.net/confluence/display/TW/Download
>>
>> Kind regards,
>> KIR
>>
>>
--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello Sascha,
Oo-oops... Will be there ASAP.
That means CVS checkout will happen on server side rather than agent side
and server will be sending out patches to agents against versions they already
have. As the matter of fact if you choose not checkout-on-server you'll have
to code checkout tasks in your build script thus, for instance, delayed commit
feature (coming...) will not work. Additionally it's real pita to configure
connection to the VCS on multiple machines for some vcses like Perforce.
That's a dream feature! But we've decided rather implement it in 1.5 release.
That actually displays those from buildAgent.properties, which are considered
like agent capabilities to match against build type requirements, though
some things could indeed be automatically treated as capabilities.
Hello Maxim,
>> - What's "checkout-on-server"?
Aha. I thought the checkout was done by the agent, but this explains the
terminology I was wondering about, like "Applying patch...".
>> - The "Compatible Agents" tab looks a bit boring. Some details about
>> each agent would be nice (Java Version, OS type, System-Properties,
>> Env, etc.) and maybe some statistics.
Oh, my bad. I've only got one agent running so far without any specific
properties. Though some statistics like uptime, number of builds run,
utilization (idle time vs. working time) might be nice as well.
Some more things/questions:
Here's something strange I just came across: I have configured a build type to
trigger on vcs changes and specified the attribute sleeping-interval-sec="60" to
do a check every 60 seconds. However, it waited 60 minutes before it
recognized a change in the vcs. Even more strange, within those 60 minutes I
actually committed 3 changes and an hour later I have 3 history entries for each
change. Is that correct? I had assumed that all changes within the "sleep
interval" should result in just one update and build.
Would it be possible to display the commit message in the "Changes" tab for each
file?
Is there a way to let my build script know about the current build number of the
project?
Can the notifications be configured in a way that one only gets notified when a
build fails? The notifications based on vcs-users that committed a change are
great, but on the long run I might get annoyed if I get a mail for each
successful checkin I make.
Sascha
Hello Sascha,
Sascha Weinreuter wrote:
>>> - The "Compatible Agents" tab looks a bit boring. Some details
>>> about each agent would be nice (Java Version, OS type,
>>> System-Properties, Env, etc.) and maybe some statistics.
>> That actually displays those from buildAgent.properties, which are
>> considered like agent capabilities to match against build type
>> requirements, though some things could indeed be automatically
>> treated as capabilities.
In fact, it is good idea, and we thought about showing such
information as well. Probably, it would be more appropriate to show such
data on "Available Agents" page. What do you think?
This issue is probably time-zone related. If you use CVS, could you
please send us the CVS server version? We'll take a look at the problem.
AFAIK, you can specify a commit message per commit, not per file. This
message is already shown on the Changes page for each commit.
Yep.
${next.successful.build.id} - is increased for successful builds
${next.build.id} - is increased always
These numbers also available as environment variables:
NEXT_SUCCESSFUL_BUILD_ID, NEXT_BUILD_ID
To edit these numbers, look for ]]>.buildNumbers.properties
file in $HOME/.BuildServer/config/ directory.
I'll add this info to FAQ.
We also plan to provide better build numbering scheme, see
http://www.jetbrains.net/jira/browse/TW-151
I don't think it is a good idea to forget about checkins you do. What
if your checkin results in deadlock?
Kind regards,
KIR
--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello Kirill,
>>>> - The "Compatible Agents" tab looks a bit boring. Some details
>>>> about each agent would be nice (Java Version, OS type,
>>>> System-Properties, Env, etc.) and maybe some statistics.
>>>
>>> That actually displays those from buildAgent.properties, which are
>>> considered like agent capabilities to match against build type
>>> requirements, though some things could indeed be automatically
>>> treated as capabilities.
>>
>> Oh, my bad. I've only got one agent running so far without any
>> specific properties. Though some statistics like uptime, number of
>> builds run, utilization (idle time vs. working time) might be nice as
>> well.
Yes, probably. I was a bit confused about the different tabs until I realized that
"Available Agents" is the "global" view and "Compatible Agents" is a per-project view.
Maybe a direct link from "Compatible Agents" to the details on the "Available Agents" page
would be good as well.
>> Here's something strange I just came across: I have configured a
>> build type to trigger on vcs changes and specified the attribute
>> sleeping-interval-sec="60" to do a check every 60 seconds. However,
>> it waited 60 minutes before it recognized a change in the vcs. Even
>> more strange, within those 60 minutes I actually committed 3 changes
>> and an hour later I have 3 history entries for each change. Is that
>> correct? I had assumed that all changes within the "sleep interval"
>> should result in just one update and build.
CVS server version is 1.11.21 running on "Red Hat Linux release 9". Timezone is
"Europe/Berlin" just as on the Team Server/Build Agent machine (WinXP SP2) and the clocks
are synchronized.
>> Would it be possible to display the commit message in the "Changes"
>> tab for each file?
Well, I guess this is a misunderstanding. I thought the commit message wasn't shown at
all, but it turned out to be a rendering-bug in IE. When selecting the content on the
page, the message appears. It also looks correctly on a different machine. Pretty strange.
>> Is there a way to let my build script know about the current build
>> number of the project?
Cool. I've seen those properties files so I was pretty sure there has to be a way. Thanks!
>> Can the notifications be configured in a way that one only gets
>> notified when a build fails? The notifications based on vcs-users
>> that committed a change are great, but on the long run I might get
>> annoyed if I get a mail for each successful checkin I make.
By deadlock you mean that the build is stuck in a loop and never completes?
The build agent should be able to detect such a condition via some timeout setting and
notify me when the build takes too long. Otherwise the only way to know would be if I
don't get notified within a certain time after the checkin, which isn't really reliable
either.
Sascha
Hello, Bas,
Thanks a lot for the screen shots!
These bugs are fixed now, so the next EAP build will support MSIE better :)
By the way, what text size do you set in your browser and what is your
screen resolution?
And do not hesitate to tell about any rendering peculiarities you see,
we'll fix them all.
Thanks for the help,
---
sasha maximova
interaction designer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello, Sascha,
Yes, seems like a bug in MSIE. We are working on more stable browser
support right now, so expect better MSIE support in the next EAP.
And of course, it would be great to hear about any rendering bugs you
encounter.
---
sasha maximova
interaction designer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
It would be wonderful to have a tool to migrate from CruiseControl and/or some of the other build tools.
I will test it in any case when I have some free time and considering the hair pulling I've done with CC, I'm guessing I'll have a lot of feedback, but anything to make the process easier would be great.
--Tim
Hello Sascha,
I've created several requests, please see details below.
Sascha Weinreuter wrote:
>>>>> - The "Compatible Agents" tab looks a bit boring. Some details
>>>>> about each agent would be nice (Java Version, OS type,
>>>>> System-Properties, Env, etc.) and maybe some statistics.
>>>>
>>>> That actually displays those from buildAgent.properties, which are
>>>> considered like agent capabilities to match against build type
>>>> requirements, though some things could indeed be automatically
>>>> treated as capabilities.
>>>
>>> Oh, my bad. I've only got one agent running so far without any
>>> specific properties. Though some statistics like uptime, number of
>>> builds run, utilization (idle time vs. working time) might be nice as
>>> well.
>>
>> In fact, it is good idea, and we thought about showing such
>> information as well. Probably, it would be more appropriate to show such
>> data on "Available Agents" page. What do you think?
http://www.jetbrains.net/jira/browse/TW-204
>>> Here's something strange I just came across: I have configured a
>>> build type to trigger on vcs changes and specified the attribute
>>> sleeping-interval-sec="60" to do a check every 60 seconds. However,
>>> it waited 60 minutes before it recognized a change in the vcs. Even
>>> more strange, within those 60 minutes I actually committed 3 changes
>>> and an hour later I have 3 history entries for each change. Is that
>>> correct? I had assumed that all changes within the "sleep interval"
>>> should result in just one update and build.
>>
>> This issue is probably time-zone related. If you use CVS, could you
>> please send us the CVS server version? We'll take a look at the problem.
The problem will fixed in the next EAP.
>>> Can the notifications be configured in a way that one only gets
>>> notified when a build fails? The notifications based on vcs-users
>>> that committed a change are great, but on the long run I might get
>>> annoyed if I get a mail for each successful checkin I make.
http://www.jetbrains.net/jira/browse/TW-202
>>
>> I don't think it is a good idea to forget about checkins you do. What
>> if your checkin results in deadlock?
http://www.jetbrains.net/jira/browse/TW-203
Thanks for your feedback!
KIR
--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"