I've just purchased a parallel build agent, but after that the free agent with 1800 minutes is gone.
Is that correct?
It was not clear from the documentation
If you are buying Microsoft-hosted CI/CD. This is the expected behavior.
You can pay for additional capacity per parallel job. Paid parallel
jobs remove the monthly time limit and allow you to run each job for
up to 360 minutes (6 hours). Buy Microsoft-hosted parallel jobs.
Source Link
Please notice our official description. After you bought one paid parallel job, you will not get a new additional parallel job. It's just move the limitation for your prefer free job. That's why your free is "gone".
Related
We are currently on the free tier of Azure DevOps which comes with 1800 free build minutes per month.
As we sometimes hit resource constraints and witness a lot of variation on the build runtime we are considering switching to a paid agent hoping that we will get more performance or at least consistency on the hosted build servers compared to the free tier.
If the paid agent does not come up to our expectation, is there a way to get back to the free tier?
If the paid agent does not come up to our expectation, is there a way to get back to the free tier?
Yes, you can simply change the Paid parallel jobs to 0 to remove the paid agents.
Or remove billing will also remove the paid agents.
Yes, you can return to the free tier, you just have to take into account the cut-off date of your bill
My question is, are the number of parallel DevOps jobs charged per-second, per-minute, or only per month?
Especially when evaluating setups (we're in the process of migrating from a TeamCity rig), we try different configurations of cloud-hosted vs self-hosted agents, and compare performance vs maintenance work and pricing.
So, say we use 15 cloud-hosted build agents for a week, and then 15 on-prem ones the next week, and then scale back to 2-3 of each for the rest of the month, will we be charged a full month for both 15 on-prem and 15 cloud agents, or do you divide the charge in sub-months, so that we could get charged for 1/4 of a month for each of the 15 on-prem and cloud-hosted agents?
It's difficult to tell from the documentation. Azure Support told me on Twitter to ask in the MSDN forums, here: https://learn.microsoft.com/en-us/answers/questions/263527/per-month-or-per-minute-billing-of-azure-devops-pi.html
But, then I found this answer, which says that DevOps is no longer suppoerted on there: https://social.msdn.microsoft.com/Forums/en-US/72cfd507-06a9-4a43-82d5-58b1eb48df56/azure-devops-pipelines-pricing-and-usage-running-on-deployment-groups?forum=AzureStack
We tested this because we need more deployment agents for 1-2 days once per month. We use Microsoft Hosted agents and they are charged per day. So we did increase the number of agents in the middle of the day and decreased back the next day and the increased charge happened for 2 days which was verified on the billing costs in Azure:
https://learn.microsoft.com/en-us/azure/devops/organizations/billing/billing-faq?view=azure-devops#q-how-much-am-i-currently-spending-on-azure-devops
If you want to verify this yourself, this shows up in Azure > Cost Management > Cost Analysis.
And filter over Service Name: Azure Devops.
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.
I wish to monitor private pool queue if there is waiting items in queue. If there is one waiting (which means that there is not enough agents to serve request) - I wish to add more VMs with agents. But I could not find any API endpoint, which will answer me, if there is any items in current pool queue.
I was not able to locate any api, which will be able to tell me how much tasks is in queue for an agent pool currently, so, I found my way around:
Query https://dev.azure.com/{instanceName}/_apis/distributedtask/pools/{poolId}/agents - this will show me how much agents I have and how much of them is online
Query https://dev.azure.com/{instanceName}/_apis/distributedtask/pools/{poolId}/jobrequests - this shows all jobs in this pool, including running one (theirs status will be null).
So, if amount of jobs is lower than amount of online agents - I am OK. As soon as amount of jobs is higher than online agents - I can employ SDK to add more agents in VMSS (until license permits, though)
Assume a team member A works with multiple projects/applications(P1,P2,P3). While doing Capacity planning, i'm able to allocate him with 8hrs per day in each project(P1,P2,P3). Is there any availability to freeze/constraint a team member's capacity to 8hrs in all projects combined(capacity should be restricted to 8hrs in combined). Any provision to create such a rule/restriction on account level?
There isn’t the feature to constraint a team member’s capacity to 8hrs in all projects. You need to do it manually.
There is a similar user voice that you can vote and follow, you also can create a new user voice for this feature.
Ability for TFS sprint capacity and days off for a project to be inherited by teams
Simple answer: You can't do this by technical means. The capacity per day field is not validated in any way. You can even enter more than 24h as capacity.
The capacity planning has to be done by organizational means.
I our projects it has proven as good practice to not even plan full 8h per day per person. For capacity planning we only assume 6h per developer. The rest is used for meetings, support and other unplanned stuff.