While other story states are self-explanatory, I'm not quite sure what is the intended use of 2 distinct Finished and Delivered states.
I have watched the videos on the Pivotal website, but found them unhelpful - they just state that we can mark the story using those states, but does not explain how does it relate to the workflow.
So, why do we need them? What happens after the developer marks the story as Finished and before it gets Delivered?
I assume the following workflow:
A developer starts to work on the story, marking it as Started
Once the story tasks are completed and it passes the unit tests - it is marked as Finished
After ??? it is marked as Delivered
Then, after QA it can be Accepted or Rejected and restarted, if necessary.
Should we mark the story as Finished before some other kind of testing and then Delivered once it passes? Or maybe it should involve code review? Perhaps this is a common knowledge in agile/scrum world, that I am yet unaware of?
I do understand that this mostly depends on the conventions, established in the project, but I am looking for some best practices, since we are just starting to incorporate Pivotal Tracker into our workflow.
I just had this same question and watched those same videos you did, but also found a more detailed article on Tracker's workflow.
Based on their explanation, I have modified your steps as below. Obviously everyone is going to have slightly different takes on this, but I've tried to see things through the way your company might work based on your initial steps.
A developer starts to work on the story, marking it as Started
Once the story tasks are completed and it passes the unit tests - it is marked as Finished
Once the code is successfully deployed to the stage or test environment, it is marked as Delivered
Then, after QA it can be Accepted or Rejected and restarted, if necessary.
Hopefully this is helpful.
That's an old subject, but here's what we are doing in my company :
When a developer ends a ticket, he finishes the story.
Any finished story has to be reviewed by another dev
If the code review is okay, the code is merged to the testing branch
Then the requester delivers it
Related
When doing end-to-end testing for Flutter, I find it very inconvenient to debug them. For example, for an e2e test that taps, drags, and asserts a ton of things, when it fails, I cannot know easily what indeed causes the failure. It may be caused by misbehavior that happens 10 steps ago.
Thus, I hope I can have the well-known time traveling functionality for Flutter tests (or, action logs, or screenshots for every step). In other words, with a button tap I can see "what did the UI look like when that button was tapped 50 steps ago?" Then I can go through the history and easily spot what goes wrong.
Is it possible to implement it? Can I integrate it into integration_test-based tests or do I have to create a brand new framework?
Here it goes: https://github.com/fzyzcjy/flutter_convenient_test - Write and debug tests easily, with full action history, time travel, screenshots, rapid re-execution, video records, interactivity, isolation and more. (With a video demo showing GUI: https://github.com/fzyzcjy/flutter_convenient_test#-quick-demo)
The implementation can be seen from the code. Shortly speaking, when actions like "tap" or "expect widget exists" are detected, some logs are created, and screenshots are automatically generated. Later, they can be displayed in a nice GUI.
It is compatible with integration_test, since we still make use of that framework and only adds automatic logging and screenshoting to it.
(Disclaimer: This is a QA style question, such that people who need it can know there already exists a library and no need to reinvent the wheel, and I am the author of the open-source library)
I use Alfresco Community 5.2 and my need is to perform some work when one of the default Alfresco's workflow is started.
I could override all the workflows definitions, but I wonder if there is a better and quicker way to do that. The perfect would be a behavior which triggers when a workflow is started.
Is there something like that ?
Any other approach is accepted. Thanks.
There isn't anything similar to a behavior for workflows that I know of, although if your workflows will always have documents attached you could consider binding a behavior to the workflow package type (I don't recall off-hand what that type is--it might just be cm:folder which wouldn't be that useful).
This is kind of a hack suggestion, but you could implement a quartz job that would run every 30 seconds or every minute or so that would use the workflow service to check to see if any new workflows have started since the last check. If so, your code could be notified and passed the workflow ID, process ID, etc.
The straightforward solution is as you suggested in your original post--just modify the out-of-the-box processes with a task listener that fires when the workflow starts.
Following Jeff suggestion, and this tutorial, I managed to implement a task creation/completion listener and do my logic inside those blocks, resolving the problem.
we are triggering the runscope test using triggerid of the specific test. How can we learn the status of the test so we can progress our builds ?
We have a blog post that describes how to do this with Codeship, but the same methods (especially the polling done in the Python sample script) should be applicable to any CI environment.
Apologies for bumping an old post, but I was looking for something similar, that is, checking the Runscope results to automatically approve the next step in a release (as opposed to a build that OP asked about).
It seems that VSTS has the concept of Gates that can do some action and only progress the release when the action succeeds, with configurable timeout and retry. One of the actions is Invoke REST API, which would probably do the job.
https://learn.microsoft.com/en-us/vsts/pipelines/release/approvals/gates?view=vsts
Note, I haven't actually tried this yet, so YMMV
I have a question regarding workflow in Kanban. Can I have two activities in my name in the "in progress" column? For example, I started the activity 'A' but not concluded and will continue at another time, then I get the activity 'B.' Makes sense to have activities A and B in the "in progress," but I'm doing only one.
I am a certified Kanban Coaching Professional, and this would be my advice:
Sure you can. Kanban itself won't say whether you can or not, it depends on how you use Kanban. The WIP limits might prevent you from starting another task, in which case you should do some or any of the following:
Discuss the issue with the team, perhaps it is ok to raise the WIP limit (or even temporarily breach it)? Perhaps you can solve the impediments together and continue working on the original task.
Perhaps you can "swarm" or help someone else with something else on the board. I usually like to start from the right-hand-side of the board and see if I can help some other item move closer to done.
You can also treat this as "slack" time, and work on improving the process, learning a new skill, or checking emails, or some of the other tasks that everyone has to do that are not directly related to the value stream. "Preparing for working on the item" is what a lot of people consider doing, but is usually just cheating against the WIP limits.
I have a web application that I am adding workflow functionality to using Windows Workflow Foundation. I have based my solution around K. Scott Allen's Orders Workflow example on OdeToCode. At the start I didn't realise the significance of the caveat "if you use Delay activities with and configure active timers for the manual scheduling service, these events will happen on a background thread that is not associated with an HTTP request". I now need to use Delay activities and it doesn't work as is with his solution architecture. Has anyone come across this and found a good solution to this? The example is linked to from a lot of places but I haven't seen anyone else come across this issue and it seems like a bit of a show stopper to me.
Edit: The problem is that the results from the workflow are returned to the the web application via HttpContext. I am using the ManualWorkflowSchedulerService with the useActiveTimers and this works fine for most situations because workflow events are fired from the web app and HttpContext still exists when the workflow results are returned and the web app can continue processing. When a delay activity is used processing happens on a background thread and when it tries to return results to the web app, there is no valid HttpContext (because there has been no Http Request), so further processing fails. That is, the webapp is trying to process the workflow results but there has been no http request.
I think I need to do all post Delay activity processing within the workflow rather than handing off to the web app.
Cheers.
You didn't describe the problem you are having. But maybe this is of some help.
You can use the ManualWorkflowSchedulerService with the useActiveTimers and the workflow will continue on another thread. Normally this is fine because your HTTP request has already finished and it doesn't really matter.
If however you need full control the workflow runtime will let you get a handle on all loaded workflows using the GetLoadedWorkflows() function. This will return acollection of WorkflowInstance objects. usign these you can can call the GetWorkflowNextTimerExpiration() to check which is expired. If one is you can manually resume it. In this case you want to use the ManualWorkflowSchedulerService with the useActiveTimers=false so you can control the last thread as well. However in most cases using useActiveTimers=true works perfectly well.