development process enforcement

> Let's get this straight, I don't want anyone to tell me what development process to follow anymore than anyone else does, however, if you are going to do development on Metacello and update configurations, then I want you to follow _my_ process.
>
> No this isn't a <rant>...no one has been monkeying with ConfigurationOfMetacello.. I've been working on adding support to MetacelloBrowser for my development process and wrestling with the problems that I may introduce for folks that have a different development style ...
>
> I think that the _style_ is where things go awry.
>
> Am I wrong or am I hallucinating due to carbohydrate withdrawal (I've just started a diet:), but it seems to me that we all can agree on the process, but we differ on how the steps in the process are performed and possibly on the order.
>
> The process is pretty basic but I think that we would all agree that if each of these steps aren't explicitly performed, we've at least justified to ourselves why we don't need to perform a particular step:
>
>   1. write code and tests with the hope that the tests provide sufficient coverage for your application
>   2. repeat step 1 until you're got something worth releasing
>   3. create release candidate deliverables (mcz files and configurations)
>   4. load and test release candidate on the set of platforms that you support
>   5. publish release candidate of deliverables and wait for feedback from actual users
>   6. mark release candidate as general release, publish and announce that new release is generally available
>
> In practice an application that has one mcz file and the change that was made is "guaranteed" not to break anything the actual steps performed might be:
>
>   1. edit code
>   2. commit mcz file
>
> No tests run, no load testing, no announcement ... For some applications this is perfectly acceptable.
>
> With Metacello the minimal steps might be:
>
>   1. edit code
>   2. commit mcz file, create new version (with #release blessing and set as #stable symbolic version), commit configuration.
>
> With the MetacelloBrowser step 2 _can_ be performed with a single menu item! Very nice and perfectly acceptable in many applications.
>
> In Metacello, GLASS, and Seaside I tend to explicitly perform each of the 6 steps (okay step 5 is done only rarely  and I tend to run through steps 1-4 in the midst of development multiple times),
>
> So the question is:
>
>   How can we shape MetacelloBrowser to support the whole range of development process styles?
>
> Without making the guy who wants to edit code and release in two steps pay a price. Without causing the Newbie to be faced with a ton of choices to make like which menu item do I use? or which menu item do I perform first? or why would I want to do that?
>
> I think I have some answers or at least some ideas that I think are interesting (remember the carbohydrate withdrawal) so I'd like to sketch out what I'm thinking for discussion ...
>
> What I'm thinking is that there'd be this checklist associated with a configuration (in the MetacelloBrowser). Pragmas of some sort in the configuration itself would control the items that are visible in the checklist.
>
> For the minimal development process above, there might be two items on the list:
>
>   1. develop
>   2. release
>
> Pressing the develop button does nothing but record that you are in development mode. Pressing the release button does the following:
>
>   - commit dirty mcz files
>   - create new version (with #release blessing and set as #stable symbolic version)
>   - commit configuration.
>
> A more standard development checklist might like the following:
>
>   1. develop
>   2. test.
>   3. create deliverables
>   4. release.
>
> When the develop button is clicked:
>
>   - create new development version (with #development blessing and set as #development symbolic version)
>
> Now the fun part, I think, when you press the test button (signaling the end of this portion of development cycle):
>
>   - tests are run
>   - if tests are green automatically jump to step 3 and create deliverables
>
> If you manually click the create deliverables or pass all the tests:
>
>   - dirtied mcz files are committed
>   - configuration updated to reflect new mcz file versions
>   - configuration committed
>
> Finally when you click the release button:
>
>   - set version blessing to #release and set version as #stable symbolic version
>   - commit configuration
>   - send email with release announcement (oh heck, why not)
>
> Of course I imagine that finer or coarser grained development sequences could be defined ... platform testing (step 4 in master list) could refuse to proceed without positive hudson results...and so on ...
>
> I am thinking that the process steps and the progress along those steps be recorded in the configuration itself (pragmas?) perhaps even the platforms that are supported should be specified, so that the fine grained progress of platform testing can be tracked and recorded ...
>
> Perhaps the buttons across the top of the MetacelloBrowser would actually be process steps ... select a configuration, click a button ... developer performs tasks ... click the next button where a check is made that all requirements are met for proceeding, automated things happen ... developer performs tasks ... clicks button ... etc.
>
> Also it's important to note that even though a config might be in the midst of development it shouldn't automatically mean that I want the development menu items ... a browse mode or develop mode choice be available ...
>
> This is enforcement I am talking about ... the enforcement of a process chosen by the developers for a project. Declaring a process and then enforcing the process through the tool, makes it possible to do lots of automated steps that wouldn't be possible otherwise.
>
> In the minimal case, what if the two steps were:
>
>   1. develop
>   2. release
>
> but the release step could automatically run the tests and would only proceed if the tests ran green?
>
> To summarize:
>
>   1. development process specified in the configuration so that different projects can follow different processes
>   2. the MetacelloBrowser enforces the _chosen_ development process for the configuration by managing the progress
>       and performing automated tasks along the way
>   3. auxilliary menu items that show up on the individual list items would then be consistent with the current
>       development step
>   4. explicit opt-in for development of a project ... the default being a browse mode...
>
> The neat thing here is that I don't think that it would be too hard to implement this ... I don't know if there's an url that you can hit on a hudson server that provides test results that can be interpreted, but beyond that I think we have the individual pieces already implemented and just need to know how to string them all together ...
>
> What do you guys think? Ravings of a carbohydrate addict?
>
> Dale
>
>

> I like the vision.
> Now, what worries me is how the development process is going to be
> specified. There would be a menu list to choose from:
>
> "It appears that you're creating a new configuration, what type of
> development process would you like to follow (it can be changed later)?"
>
> - I want to code for myself and not share with anyone
> - I want to just do some development and then when commiting do a
> release. No animals are killed by my code so why bother in test :)
> - I want to follow the develop, run test, deploy on platforms and
> release cycle. Give it to me please!
>
> And the this will store a pragma somewhere for the MetacelloBrowser to
> honor and use when deciding what next action to offer the developer in a
> given state of the development with metacello?
>
> If it is that easy I buy it.
>
> Cheers
>
> El jue, 24-02-2011 a las 11:45 -0800, Dale Henrichs escribió:
>> Let's get this straight, I don't want anyone to tell me what development process to follow anymore than anyone else does, however, if you are going to do development on Metacello and update configurations, then I want you to follow _my_ process.
>>
>> No this isn't a <rant>...no one has been monkeying with ConfigurationOfMetacello.. I've been working on adding support to MetacelloBrowser for my development process and wrestling with the problems that I may introduce for folks that have a different development style ...
>>
>> I think that the _style_ is where things go awry.
>>
>> Am I wrong or am I hallucinating due to carbohydrate withdrawal (I've just started a diet:), but it seems to me that we all can agree on the process, but we differ on how the steps in the process are performed and possibly on the order.
>>
>> The process is pretty basic but I think that we would all agree that if each of these steps aren't explicitly performed, we've at least justified to ourselves why we don't need to perform a particular step:
>>
>>  1. write code and tests with the hope that the tests provide sufficient coverage for your application
>>  2. repeat step 1 until you're got something worth releasing
>>  3. create release candidate deliverables (mcz files and configurations)
>>  4. load and test release candidate on the set of platforms that you support
>>  5. publish release candidate of deliverables and wait for feedback from actual users
>>  6. mark release candidate as general release, publish and announce that new release is generally available
>>
>> In practice an application that has one mcz file and the change that was made is "guaranteed" not to break anything the actual steps performed might be:
>>
>>  1. edit code
>>  2. commit mcz file
>>
>> No tests run, no load testing, no announcement ... For some applications this is perfectly acceptable.
>>
>> With Metacello the minimal steps might be:
>>
>>  1. edit code
>>  2. commit mcz file, create new version (with #release blessing and set as #stable symbolic version), commit configuration.
>>
>> With the MetacelloBrowser step 2 _can_ be performed with a single menu item! Very nice and perfectly acceptable in many applications.
>>
>> In Metacello, GLASS, and Seaside I tend to explicitly perform each of the 6 steps (okay step 5 is done only rarely  and I tend to run through steps 1-4 in the midst of development multiple times),
>>
>> So the question is:
>>
>>  How can we shape MetacelloBrowser to support the whole range of development process styles?
>>
>> Without making the guy who wants to edit code and release in two steps pay a price. Without causing the Newbie to be faced with a ton of choices to make like which menu item do I use? or which menu item do I perform first? or why would I want to do that?
>>
>> I think I have some answers or at least some ideas that I think are interesting (remember the carbohydrate withdrawal) so I'd like to sketch out what I'm thinking for discussion ...
>>
>> What I'm thinking is that there'd be this checklist associated with a configuration (in the MetacelloBrowser). Pragmas of some sort in the configuration itself would control the items that are visible in the checklist.
>>
>> For the minimal development process above, there might be two items on the list:
>>
>>  1. develop
>>  2. release
>>
>> Pressing the develop button does nothing but record that you are in development mode. Pressing the release button does the following:
>>
>>  - commit dirty mcz files
>>  - create new version (with #release blessing and set as #stable symbolic version)
>>  - commit configuration.
>>
>> A more standard development checklist might like the following:
>>
>>  1. develop
>>  2. test.
>>  3. create deliverables
>>  4. release.
>>
>> When the develop button is clicked:
>>
>>  - create new development version (with #development blessing and set as #development symbolic version)
>>
>> Now the fun part, I think, when you press the test button (signaling the end of this portion of development cycle):
>>
>>  - tests are run
>>  - if tests are green automatically jump to step 3 and create deliverables
>>
>> If you manually click the create deliverables or pass all the tests:
>>
>>  - dirtied mcz files are committed
>>  - configuration updated to reflect new mcz file versions
>>  - configuration committed
>>
>> Finally when you click the release button:
>>
>>  - set version blessing to #release and set version as #stable symbolic version
>>  - commit configuration
>>  - send email with release announcement (oh heck, why not)
>>
>> Of course I imagine that finer or coarser grained development sequences could be defined ... platform testing (step 4 in master list) could refuse to proceed without positive hudson results...and so on ...
>>
>> I am thinking that the process steps and the progress along those steps be recorded in the configuration itself (pragmas?) perhaps even the platforms that are supported should be specified, so that the fine grained progress of platform testing can be tracked and recorded ...
>>
>> Perhaps the buttons across the top of the MetacelloBrowser would actually be process steps ... select a configuration, click a button ... developer performs tasks ... click the next button where a check is made that all requirements are met for proceeding, automated things happen ... developer performs tasks ... clicks button ... etc.
>>
>> Also it's important to note that even though a config might be in the midst of development it shouldn't automatically mean that I want the development menu items ... a browse mode or develop mode choice be available ...
>>
>> This is enforcement I am talking about ... the enforcement of a process chosen by the developers for a project. Declaring a process and then enforcing the process through the tool, makes it possible to do lots of automated steps that wouldn't be possible otherwise.
>>
>> In the minimal case, what if the two steps were:
>>
>>  1. develop
>>  2. release
>>
>> but the release step could automatically run the tests and would only proceed if the tests ran green?
>>
>> To summarize:
>>
>>  1. development process specified in the configuration so that different projects can follow different processes
>>  2. the MetacelloBrowser enforces the _chosen_ development process for the configuration by managing the progress
>>      and performing automated tasks along the way
>>  3. auxilliary menu items that show up on the individual list items would then be consistent with the current
>>      development step
>>  4. explicit opt-in for development of a project ... the default being a browse mode...
>>
>> The neat thing here is that I don't think that it would be too hard to implement this ... I don't know if there's an url that you can hit on a hudson server that provides test results that can be interpreted, but beyond that I think we have the individual pieces already implemented and just need to know how to string them all together ...
>>
>> What do you guys think? Ravings of a carbohydrate addict?
>>
>> Dale
>>
>>
>
> --
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
>
>
>