[Anthill-pro] Functional tests configuration best practices
Ryan Smith
rws at urbancode.com
Wed Mar 26 13:20:23 CST 2008
I would just like to note, that in the next release, the properties of the originating workflow will be available on the non-originating workflows as was attempted.
Ryan Smith
Varban wrote:
> If you set the tagToReleaseFrom on the originating workflow, that
> variable is available only for this workflow and thus unavalable for
> your deploy workflow.
>
>
> emerson cargnin wrote:
>> It worked fine when I do CI builds. For my build from the tag workflow
>> though I'm getting a problem.
>>
>> On my "build from the tag" workflow I use a variable to tell which is
>> my tag.
>>
>> This is one of my source paths on the tag field:
>>
>> ${property:tagToReleaseFrom}/modules
>>
>> When it comes to the deploy workflow, on my post deployment steps it
>> seems like its not resolving that variable. Here is the log:
>>
>> Subversion command line: svn log --non-interactive --verbose
>> --revision {2008-02-25 14:21:44 +0000}:{2008-03-26 15:56:12 +0000}
>> http://subversion/svn/myrepo/tags/${property:tagToReleaseFrom}/resources/resourcesTemplates/APPS
>>
>>
>> shouldn't it resolve the "tagToReleaseFrom" to the original workflow
>> variable?
>>
>> thanks
>> emerson
>>
>>
>> On 25/03/2008, Steve Boone <sbb at urbancode.com> wrote:
>>> Emerson.
>>>
>>> Here are the steps.
>>>
>>> 1) Assign status Step, that uses the following script to determine the
>>> status.
>>>
>>> return ServerGroupLookup.getCurrent().getName();
>>>
>>>
>>> 2) JIRA resolve issue step. This step uses a issue key based on a
>>> property
>>> to resolve the JIRA issue.
>>>
>>> 3) SVN Get changelog step. This step is to get the changelog since
>>> the last
>>> deployment, and uses the same status that was applied in step 1
>>>
>>> return ServerGroupLookup.getCurrent().getName();
>>>
>>>
>>>
>>> 4) Changelog publisher, publishes the changelog in step 3.
>>>
>>> 5) Stamp Step. This step applies a stamp based on the evironment we
>>> deployed too. Again, the code is.
>>>
>>> ServerGroupLookup.getCurrent().getName();
>>>
>>> Thats all there is too it, let me know if you have any other questions.
>>>
>>> On Tue, Mar 25, 2008 at 1:58 PM, emerson cargnin
>>> <echofloripa.yell at gmail.com> wrote:
>>>> Rewgarding the "post deployment steps" job posted on the CM
>>>> presentation , which is the status assigned at the beggining of the
>>>> job? I really would like to see the content of each of the steps.
>>>>
>>>> If it's not easy to get an entire release of the server with the
>>>> xpetstore, a suggestion would be to create a user that could only see
>>>> the configuration on your own server.
>>>>
>>>> thanks
>>>> emerson
>>>>
>>>>
>>>>
>>>>
>>>> On 25/03/2008, emerson cargnin <echofloripa.yell at gmail.com> wrote:
>>>>> Hi Eric
>>>>>
>>>>> So any chance that we could get ower hands on a full implementation of
>>>>> the XPetStore on AHP? I think this would be a great help for all.
>>>>>
>>>>> thanks
>>>>> emerson
>>>>>
>>>>> On 06/03/2008, emerson cargnin <echofloripa.yell at gmail.com> wrote:
>>>>>> Thanks, but still, it would be of great value to have a full fledge
>>>>>> project on anthill to people learn from and to learn good practices.
>>>>>>
>>>>>> also regarding job libraries, there seems to not have much
>>>>>> documentation available about it, only a short explanation how to set
>>>>>> it or to use it in other workflows. It would be really great if
>>>>>> someone could step in and tell how to best re-use it job libraries,
>>>>>> how extract variables out of the job library (i presume using project
>>>>>> properties), what are the best granularity to have jobs libraries and
>>>>>> so on
>>>>>>
>>>>>> thanks
>>>>>> emerson
>>>>>>
>>>>>> On 29/02/2008, Eric Minick <etm at urbancode.com> wrote:
>>>>>>> Hi Emerson,
>>>>>>>
>>>>>>> On the separation of the deployment and functional test workflows,
>>>>>>> either approach is fine. Generally you don't want to run functional
>>>>>>> tests on every deployment since that doesn't always make sense in
>>>>>>> production, but if the deployment process is fast, you can redeploy
>>> on
>>>>>>> every functional test execution.
>>>>>>>
>>>>>>> The post-deployment steps are pretty typical practice. The most
>>> common
>>>>>>> item there is the promotion to the status matching the environment
>>> we
>>>>>>> deployed to. We decide not to grant that status unless both parts of
>>> the
>>>>>>> deployment work successfully. Neither job knows much about the
>>> other, so
>>>>>>> we need a third job to execute afterwards that runs that step. We
>>> have
>>>>>>> some other steps tossed in there as well, but that's the main one
>>> that
>>>>>>> needs to be there.
>>>>>>>
>>>>>>> We should be able to show you the configuration, send an email to
>>> one of
>>>>>>> the guys in the office with some times that work for you and they
>>> can
>>>>>>> probably get something set up.
>>>>>>>
>>>>>>> -- Eric
>>>>>>>
>>>>>>> emerson cargnin wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> At this moment I have my deploy workflow to call the functional
>>> tests job.
>>>>>>>> I saw in the CM crossroads presentation a build life for the
>>> XPetstore
>>>>>>>> and it shows a workflow as a separate workflow. Also in the deploy
>>>>>>>> workflow you have a post deployment steps, I'm interested in
>>> seeing
>>>>>>>> what you have on that one.
>>>>>>>>
>>>>>>>> I would be really really really helpful if I could get my eyes on
>>> this
>>>>>>>> configuration.
>>>>>>>> I thing I could extract a great amount of best practices from
>>> there.
>>>>>>>> Or you could make it available as an read only user for this
>>> project
>>>>>>>> or you could setup a full version that I could import into a derby
>>> db
>>>>>>>> configured AHP.
>>>>>>>> Either way I think this could help a lot, not only me as a lot of
>>> AHP
>>>>>>>> users that sometimes feel unsure on the best way of doing trivial
>>>>>>>> tasks.
>>>>>>>>
>>>>>>>> also, should the functional tests workflow an originating one? If
>>> not,
>>>>>>>> I would have to find out to which server I deployed the build so
>>> that
>>>>>>>> |I could run the tests against it. It would be good to have some
>>> ideas
>>>>>>>> on this subject.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Emerson Cargnin
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>
--
===========================================================
Ryan Smith. 2044 Euclid Ave., Suite 600
Developer Cleveland, Ohio 44115
Urbancode, Inc.
email: rws at urbancode.com
web: www.urbancode.com phone: 216-858-9000
web: www.anthillpro.com fax: 216-858-9602
===========================================================
More information about the Anthill-pro
mailing list