[Anthill-pro] Will anthillpro Supports C++ Build in Linux OS

Mon Aug 20 07:53:47 CDT 2007

Anthill Support,

I am trying to install your 30 day trail s/w and test the requirements. May
I know what all steps I need to install and run and setup my prototype.

My environment is Linux 8.0 Server, C++ and JAVA code that I need to build
for releases and Source Code is in CVS.

Can you please send me the

   1. User Guild to install anthill in Linux Server and Client machines.
   2. User guide to connect to CVS.
   3. User Guide to setup the initial setup for Compile, Link and build
   the .tar files for release.

Thanks
Joe

On 8/14/07, Eric Minick <etm at urbancode.com> wrote:
>
>
>
> Joseph wrote:
> > Thanks Yanko for quick email, i am researching for a unique tool that
> > supports the below requirements. Please mention "Y" for yes and "N" for
> No
> >
> >  Builds requirement
> >
> >
> > 1 The system shall perform builds which include source extraction,
> compile,
> > link, and package for instillation.
> >
> Yes. This is pretty much bread and butter for the build part of the tool.
> > 2.   The system shall manage builds with make and or data files that are
> > revision controlled with the source code.
> >
> Yes.
> > 3. The system shall build boot code, kernel, operating file system and
> > content and application software for all software and firmware within an
> > instrument product. This includes any non source binaries that are used.
> >
> Yes. Could you clarify non-source binaries. There may be some nice
> features around this.
> > 4. The system shall build components that originate as unchanged open
> source
> > packages, from their distributed format. This includes but is not
> limited to
> > uncompressing and unpacking of directory structures of source, make and
> data
> > files. This automation is to enforce use of unchanged external packages
> or
> > the tracking of any changes made to external packages.
> >
> Yes ( I think ).
>
> Could you clarify? Are you looking for Anthill to take a source tarball,
> unzip it, and then run a file system based change-log (basically detect
> which files are of a different date) against the unrolled directory?
> That should work fine if the unchanged files don't have a new date
> stamp, but I somewhat doubt that's true.
>
> Generally, we encourage teams to load those 3rd party binaries into
> Anthill's CodeStation tool, and number them with the release number
> provided by the 3rd party. The change logs publicly published by the
> open source tool provider should be better than whatever we can
> automatically produce. So long as the the build and release tool allows
> you to identify which release of the open source project the binary is
> associated with (and Anthill does) the public information is probably
> superior.
>
> We also see teams grabbing the publicly available change log and dumping
> it into a text file which is loaded into CodeStation alongside the
> tarball. That provides insulation against the open source project
> disappearing and the lost of the change information.
>
> CodeStation really pushes binary reuse, so if you could just load up a
> pre-compiled binary of the 3rd party library, that would be even better.
>
> If you wanted to do something really interesting, you could probably
> model the open source library as full project with a self referential
> dependency and run a recursive diff that highlights the changes since
> first version that was loaded in. That would require some bootstrapping,
> and I'm not sure it's been done before, but it would be quite doable
> with some help from the support team.
>
> But overall, I'm inclined to agree with Curtis that the approach here
> may be less than ideal. Perhaps I don't understand the requirements
> though. What's the 'real' requirement here that led to #4? If it's just
> clear, consistent reuse of 3rd party libraries, Anthill has you covered.
> > 5.The system shall support the export and import of code sets for work
> by
> > outside contractors.
> >
> N/A. This really is going to be mostly under the control of your source
> control / change management tool. Anthill won't stop you from doing it,
> but I'm not sure how it's going to be aware of it either. If you think
> it should be, please clarify.
> > 6   The system shall support controlled r/w source access to the system
> by
> > outside contractors.
> >
> Yes. There is clear role based security. You can determine who can do
> what within the system. So a contractor might be able to see the status
> of builds on (only) the project she is working on, but not be able to
> configure that build. Whether the contractor can kick off authoritative
> builds is up to you as well.
> > 7. The system shall perform the appropriate labeling and data tracking
> for a
> > builds tracking back to every individual source and data file used in
> its
> > creation.
> >
> Yes. The system can definitely apply a label back to source control at
> build time if you want it to. It can also do so at build promotion time.
> Once accomplished, it will be easy within the source control tool to
> know who last touched any given file. Anthill is also explicitly aware
> of changes between builds and knows which user touched which file when.
> > 8. The system shall produce release builds with intermediate file and
> final
> > targets placed within the controlled system area and within a
> developer's
> > local area.
> >
> Generally, developer builds are outside the scope of what Anthill sets
> out to do (see #9). But it will definitely produce authoritative builds.
> After producing an authoritative build, it will generally store the
> resulting binaries internally and when prompted to deliver them to a
> deployment target (like the controlled system area) it will do so.
> Deployments of this type are part of the reason why Anthill isn't really
> just a build tool. We like the term 'application lifecycle automation'.
> > 9.  The system shall perform release builds triggered by a schedule,
> > developer request.
> >
> Yes. Authoritative builds can be triggered manually, by schedule (simple
> or cron like), event within the system, commit into source control, or
> the completed build of a dependency. Which options are active are up to
> you.
>
> Note that I use the term 'authoritative' rather than 'release'. The
> presumption is that you don't know which build will be released at build
> time, so more builds are done that are releaseable. Perhaps only when QA
> approves a build is it released and marked as such in Anthill.
> > 10.The system shall perform developer builds triggered by and developer
> > local on demand.
> >
> This is a very uncommon useage pattern but possible. It absolutely can
> be done by installing agents on developer machines and having a custom
> workflow that selects them. This model is uncommon though. Usually,
> developers will build locally running the same scripts that Anthill uses
> to build authoritatively.
>
> Outside resources (like open source libraries) can be provided on the
> fly to the developers at build time in a similar way that they are
> injected into the authoritative builds. That simplifies things so the
> developer just has to run make. They don't have to log into a website to
> do a build on their own machine.
>
> Doing thier own builds with the build scripts has been found to be
> healthier and keep the build scripts in better shape.
> > 11.The system shall builds for the current work at the head of a
> development
> > branch or tree.
> >
> >
> Yes.
> > 12.The system shall builds for defect repairs or small functional
> additions
> > to any released code set.
> >
> Yes, but less common. Usually defect repairs are done by branching a
> release and committing defect fixes into that branch. That's easy. For
> some source control  tools, we see teams use the label that Anthill sets
> down as a baseline and they'll have a running target baseline. They'll
> fetch the baseline version of the code, and then check out a change set
> overlayed on top of it for a defect patch.
>
> A more common approach would be to build the project as a large number
> of independently built sub-modules and use dependency rules to assemble
> those modules. In a break-fix scenerio, only the impacted module would
> get a new build, and it would be assembled with the already approved
> versions of the other modules. Explicit build statuses provide support
> for notions like "the approved version of a sub-module".
> > Please guide me and let me know if AntHillPro supports above or is there
> any
> > other tool that supports this requirements
> >
> >
> Thanks Joe. You may have noticed that I used terms like "generally" and
> "usually" a lot. There's a lot of flexibility in the tool, but there are
> also some best practices (I hate that term) and assumed useage patterns.
> The more you deviate from those patterns, the more help you'll likely
> need from the support team. The good news there is that the support team
> are nice guys.
>
> You might want to contact sales at urbancode.com for a demo of the product
> and a more detailed discussion. They're also nice guys and aren't going
> to try a hard sell on you.
> > Thanks
> > Joe
> >
> > On 8/13/07, Curtis Yanko <curt_yanko at uhc.com> wrote:
> >
> >> Of course.
> >>
> >> - Curtis Yanko
> >> UnitedHealth Group IT
> >> Source->Build->Deploy
> >> Mail Route: CT028-06SA
> >> Internet email: curt_yanko at uhc.com
> >> Office 860.702.9059
> >> Cell 860.729.8171
> >>
> >>
> >>
> >>   *Joseph <yjvijay at gmail.com>*
> >> Sent by: anthill-pro-bounces at caladin.urbancode.com
> >>
> >> 08/13/2007 10:47 AM   Please respond to
> >> "AnthillPro user and support list." <anthill-pro at caladin.urbancode.com>
> >>
> >>    To
> >> anthill-pro at caladin.urbancode.com  cc
> >>   Subject
> >> [Anthill-pro] Will anthillpro Supports C++ Build in Linux OS
> >>
> >>
> >>
> >>
> >> Hi Gurus,
> >>
> >> May i know weather anthillpro Supports C++ Builds in Linux OS? I have a
> >> requirement that the Tool should build C++ tarballs nightly and on
> local
> >> developer demand.
> >>
> >> Please guide me.
> >>
> >> Thanks
> >> Joe _______________________________________________
> >> Anthill-pro mailing list
> >> Anthill-pro at lists.urbancode.com
> >> http://lists.urbancode.com/mailman/listinfo/anthill-pro
> >>
> >>
> >>
> >> This e-mail, including attachments, may include confidential and/or
> >> proprietary information, and may be used only by the person or entity
> to
> >> which it is addressed. If the reader of this e-mail is not the intended
> >> recipient or his or her authorized agent, the reader is hereby notified
> >> that any dissemination, distribution or copying of this e-mail is
> >> prohibited. If you have received this e-mail in error, please notify
> the
> >> sender by replying to this message and delete this e-mail immediately.
> >>
> >> _______________________________________________
> >> Anthill-pro mailing list
> >> Anthill-pro at lists.urbancode.com
> >> http://lists.urbancode.com/mailman/listinfo/anthill-pro
> >>
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Anthill-pro mailing list
> > Anthill-pro at lists.urbancode.com
> > http://lists.urbancode.com/mailman/listinfo/anthill-pro
> >
>
> _______________________________________________
> Anthill-pro mailing list
> Anthill-pro at lists.urbancode.com
> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-pro/attachments/20070820/e8228ffa/attachment-0001.htm