I am modeling an development process where projects (Epics) come from the Source and are broken down into their components (Features) that go through development. Once those components (Features) are completed the project (Epic) is complete. Here are the model detail (see screen shot too). enter image description here
Epics agents (main project) leave the source and are copied with a random number of copies by the Split block into Features agents (the components of the main project).
Epics agent is linked bi-directionally with Feature agent. At "On exit copy" the connection is made with "agent.ConnectTo(original)".
The Feature agents then move to one of 2 Service block for development based in the probability set in a SelectOutput.
The Epic moves immediately to a Wait (epicWait) and will remain there until all the copied agents (Feature) have moved through their development Service blocks.
When an Feature leaves the development Service it goes to a Wait block (featureWait1 or 2) where it needs to check to see if all the Feature agents that went to the other development block are complete. If so the Feature agent should free itself, the other Feature agents in the other featureWait, and the matching Epic agent that is waiting in the epicWait. This signifies the project (Epic) is complete.
So my questions are how do I write the On Enter function to check the other featureWait block for other linked Feature agents? And then how do I free them to signify the epic is now complete? Thanks,
What I would do instead of using featureWait1 and 2, on the sinkFeature1 and 2 I would do
if(agent.EpicLink.getConnectedAgent().featureLink.getConnectionsNumber()==1){
epicWait.free(agent.EpicLink.getConnectedAgent());
}
agent.EpicLink.disconnect();
where epicLink represents the connection in the feature agent that is the connection to the associated epic
Related
Problem is explained in the image below
The detail of the agent which I am using:
Detail on the Service in which I am using Resource Pool:
Process Flow:
I used seize-move-release, in order to move the agent with the Resource. showing in figure below
Problem:
Now the only problem is, how 2 Agents will wait in the queue for there turn to go to the Delay section. Explanation is in the image below.
so it seems that most of this flow is wrong if your intent is for the resource to take the agent somewhere.
You are looking at the resource move alone because it's probably going back home
In order to use the resource to move your agent, you need to use seize-move-release, not a service block
I hope this helps
I am working on a ticketing model framework, where we receive requests for single or bulk user account creation in an SAP system. The request is an agent which have multiple agents - user(s) inside it.
So, as you can see in the image we have
Source - Request is coming from here.
Delay(createRequestNo) - A request no. is assigned to the Request at this block.
Service(userCreation) - User(s) are created at this block.
Sink - Request (agent) goes out from this block.
resourcePool - A team of 15 who works on creating user accounts. It is linked to service block.
Imagine a bulk request comes in to create 5 users.
How do the resources at the service block process the all 5 user agents which are inside a Request agent here?
You say your Request agent that flows through the process flow has a number of Agents in it, but these don't need to be agents, they can be pure Java classes or requests can also simply carry a number of users to create.
It all depends on the granularity you require
To answer your question you can access the inside of the agents that travels through the process flow and use that to determine the delay or the number of resources to be seized as follow:
Just be sure that the Agent type in the advanced setting is set to the Agent type that you expect in this block. If you set the Source to create a specific agent type it will automatically update all the serially connected blocks for you.
Please note if the user creation process will vary for each user to be created you need a separate delay for each user... and thus it would be better to split into multiple agents for each user creation, and then have them seize, delay and release each resource separately.
With your current logic, they will all be seized and released at the same time.
We are developing a complex system using scrum methodology with 1 week sprints and a team of 6 developers.
We continuously update the source code on every developer machine when the changes are tested and integrated on the development branches, and the developers daily integrate the changes to a test common server.
But the production system is critical enough for any issue or downtime to cause much $ lost, and the deployment process is slow, hard and delicate. Even if the system changes are tested and even deployed to a test server, sometimes problems arise when we try to publish the whole week progress as a lot. Thus, we have chose to have a previous deployment process which happens after all the week development is completed and deployed to the test server. We run full feature tests on the whole week changes on the test server, then publish the week work lot to a preproduction server, then sometimes everything goes fine but sometimes some new problems arise on the deployment process or the published changes, then we plan the highly delicate production process and execute it on the next night we can, avoiding any downtime for the customer work.
Now, we are having discussions with the customer since he defends this is not scrum because he isn't gettint the sprint result on the scrum day, but three days later. But obviously we can't start the pre-release and release process until the sprint completes totally - so, next day - and then the system complexity and criticality forces us to secure the deployment process to the top, and the customer production usage requires also some special operation scheduling.
Are we working against the scrum guidelines? Where is the deployment process on the scrum methodology? Is scrum appropiate for this project?
the deployment process is slow, hard and delicate.
When a deployment process is hard, it tends to mean organisations deploy less frequently. If they deploy less often then releases become bigger, more difficult and more critical. This tends to mean that there is even more reluctance to release.
This negative cycle works against Agile as it means organisations struggle to respond to change.
The best thing you can do is try and break out of this cycle by improving the release process. This may be difficult and consume time and resources, but the benefits are significant.
If you can automate your releases then you tend to reduce the risk. With the risk lowered then releasing more frequently becomes possible. Frequent releases means that the size of releases is reduced and you can quickly fix bugs if necessary.
Frequent releases also make the customer happier as they get more opportunities to provide feedback. The more feedback they give, the sooner the product will be what they want.
Perhaps a good place to start would be to automate the releases you currently make to the common test server. Once you have been doing this for a while you should have the confidence to use the same process on production.
Barnaby has the ideal answer. In the meantime, one possibility is to have a repeating story each sprint to release the approved stories from the previous sprint. Per the Scrum Guide, a team only delivers "a potentially releasable Increment of (a) 'Done' product at the end of each Sprint." The key word is "potentially." In addition to the problem you face, I have been in companies that only released once a quarter because that is what the customers wanted. If your customer wants a release every sprint, great, but nothing in the guide requires that to happen in the same sprint the stories are accepted in.
To clarify based on the comment, let's assume a team is using a traditional Dev-Test-Stage-Production architecture. The customer would review the changes in Stage (during the Demonstration Ceremony if not before). Accepted stories go into the release, which moves to Prod as part of the recurring "Release" story in the next sprint.
From this link it appears that Agents have been renamed to Pipelines. https://www.visualstudio.com/en-us/docs/setup-admin/team-services/get-more-build-or-load-testing-vs
It also states that "Private agents are now free and unlimited." From Build & Release, Resource Limits, I show one free Pipeline.
We tried to add a second private agent to our VSTS and received the error:
"No more private agent slots available, please purchase more. For more information visit: https://go.microsoft.com/fwlink/?LinkID=623705 Current max: 1 Xaml Controllers: 0 Build Agents: 1"
From the link above it'd appear we did what we needed to do and should be able to add aditional agents. Any idea why we can't add an additional agent and Current max is 1?
Thanks for reporting this. It looks like there is a problem with the logic so the engineering feature team is going to deploy a fix that should fix this problem. You are right: you can have unlimited agents and concurrent pipelines is what we are transitioning to charging for where pipelines can leverage multiple agents if needed.
We have not switched from the agent-based model to pipeline model yet in Team Services. As we are still in the agent-based model, you will see this error if you have not purchased enough agents. We plan to switch to the pipeline model late January or early February.
I have an state machine implemented using wwf which is going to handle an indent flow.
Imagine that we have an indent registered by user and we want to send enquiry to different vendors.
the number of enquiries are various and depends on buyer's decision that how many vendors he wants to enquire.So my state machine comes to an state named Waiting for Enquiry and I need fork here and I have different state among this fork ( I think I have to add a nested state machine) I'm adding a parallel activity but the branches of this parallel activity are depended on selected vendors as I mentioned above.when I try to add branches dynamically I receive exception because the workflow is not mach with the persisted one.
is there any solution?
Sounds like you want to use the ParallelForEach instead of a Parallel with multiple branches.