We had a few cases when:
Someone changes a task group (or build/release/whatever).
Makes some mistake.
Then publishes/saves it.
But doesn't notify anyone that such changes were made.
Some hours later some dependent build breaks because of those changes.
And we have to spend even more time trying to find what and when has changed as it is not often that simple to find out with external task groups.
What we want to have:
Ideally - some approval process for such changes. Kind of like code review, but for task groups/builds.
If not - then at least some way to receive notifications about changes in task groups and etc. we are interested in?
I found neither, and, honestly, doubt that such features are present in the TFS version we use (TFS 2018.2), but perhaps I've missed something.
There isn't any workflow security or approval process for the groups. You could suggest that kind of feature on the developercommunity. Restrict access to edit Task Groups to only those who understand how to bump the Task Group version. That way at least you will keep backward compatibility across your builds unless that explicitly upgrade to that version.
There aren't any built in notifications, but you could create an automated process to send email notifications using PowerShell using the existing API.
Get the Id for the task group using the taskgroups list api
Use the revisions api to get the history _apis/distributedtask/taskgroups/{taskgroupid}/revisions
Send an update for anything that edited today
Related
I would like to check in code after a code review is approved. I came across this stack about creating code reviews and checking in, but my question is a little different.
My issue is that I want to create a code review; however, I do not want to check in the code until it is approved. That limits me from being able to start another code review with removing related work items. What I would like to do is create code reviews and check in from the code review tab in the Team Explorer
Is that possible? It is the same principle as creating a code review after the check in, but with Code reviews and checking in. I do not want to go to pending changes and check in there because I may have removed the related items. But I do want a check in to be tied to my code review.
Unfortunately, there is no "proper" way to do what you are trying to do. You could have your working directory on a shared drive and just notify your reviewer when you are ready for them to start their review process, but that side-steps the accountability by not having each development/review iteration officially logged within TFS. This means you should check in your work and let the reviewer do their job, then continue on in that fashion to make any changes requested by the reviewer, check in, and get another code-review.
For completeness I will mention my suggestion from my comments here as well.
My suggestion would be to create a self-contained, short-lived development branch where you will do your development and have your code reviewed. Then once the development and reviewing has been completed to satisfaction, that branch can be merged back up and destroyed. This provides a much cleaner and safer approach. 1) It reduces the clutter in the history within TFS. 2) It prevents multiple unnecessary automated builds/tests/etc... from being triggered.
In your comment you suggest that this changes the "structure of your branching methods". I don't see how doing this changes anything in any way that matters. Your merge would be just like your final development check-in except that by this time all reviews have been completed and you are performing a single, clean check-in. It will still contain all of your check-in and review information, however instead of a cluttered chain of check-ins, you will have a single collapsed node which contains every single thing that was done for that particular task.
I would check with your manager, your code reviewer and/or anyone you have that is in charge of TFS and creating/maintaining your TFS policy. This approach really doesn't change anything in regard to how the rest of your process works. You would have simply abstracted your development cycle to a self-contained environment. The second you perform your merge you are right back into your normal process as you have it now.
Okay, so for documentation purposes. I did not fully understand the shelving that TFS allow me to do. After reading Shelve and Unshelve Pending Changes, it makes more sense to me. I can shelve what I am working on, unshelve the code that I have done a code review for, then check in that code. That way I can create a code review and continue working until that code review is approved. Once approved, I can go unshelve the changes and check it in.
I have a web application with Rails 4 where you have to log in to use it. Now I want a demo version of this app. By demo version I mean a version that has all the features of the original app but without the login. And all the demo data should (and can easyliy) be deleted from time to time (either automatically or manually).
With the original app up and running I want to implement the demo version with the least effort. Ideally I can use most of the original code without any changes. But changes to the original code on the other hand will be available in the demo version without any extra work.
My first idea was to implement the demo version just in the cache/session so if the session is expired, the data is deleteded as well. I canceled that idea due to the deep integration of ActiveRecord in the original app. I would have to re-code all the demo classes and/or build some abstract parent classes and so on.
The second idea was to simply use the original app but to add a flag to each demo account so that they can be distiguished from all the regular ones. I hesitate with this idea because I'm afraid to blow up my database (i.e. the tables that I use for the original app) with demo data leading to lower performance and higher cost/risk of wrong interpretations when evaluating the app data (e.g. how many accounts where created yesterday).
Do you have any ideas how to realize such a demo version in an elegant way?
Smart approaches welcome!
You can have a Guest user account, and a before action in ApplicationController that checks if the current application is in demo mode (specifiable through a custom config) and automatically logs in the user.
You can use a cron job to delete the demo data. Whenever is a good solution for managing cron jobs in ruby.
for automated fake data creating use whenever and faker gems. Faker will generate fake data. Whenever for cron job. And after every demo session it will clear the mock data.
take these point : session, cron, fake seed data
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have a small team of developers that use bitbucket as our git repository.
I want to know how to limit who can merge code on a pull request in bitbucket? AND/OR force at least one approval before the merge can be done. Basically I am looking to force a code review.
As of now the creator of a pull-request (and everyone else) can not only approve but also merge the code in which can be an issue for quality purposes. Thanks in advance.
Update:
Bitbucket now allows for control over push permissions, branch deletion, and history re-writing. The full management instructions are here: https://confluence.atlassian.com/bitbucket/branch-management-385912271.html
There still is not a way to force a minimum number of approvals however.
I want to know how to limit who can merge code on a pull request in bitbucket? AND/OR force at least one approval before the merge can be done. Basically I am looking to force a code review.
This functionality is not available in Bitbucket right now, but Atlassian's behind-the-firewall version of Git hosting has it.
Stash allows you to:
limit who can change branches
enforce a minimum number of approvals before merging pull requests (it can do a similar thing for Bamboo builds - i.e. the code must compile before it can be merged)
reset approvals if a pull request changes
It's a curious asymmetry in Atlassian's own products.
Answer from attlassian:
Mary Anthony [Atlassian Technical Writer]
Hi,
So, a repository can have branches. Within that repository, you can't
set permissions on a branch that are different from the repository.
You can set permissions on the repository that would allow developers
to fork the repository and issue pull requests against it. To
configure this:
Create a group on your account and call it "developers".
Give the group read permissions.
Add all the developers to that group.
Edit the groups on the repository and add developers.
Hope this helps.
Mary
Here it is: https://confluence.atlassian.com/display/BITBUCKET/Work+with+pull+requests?focusedCommentId=321851850#comment-321851850
In other words, you can make your dev fork the project and issue pull requests from their fork. In your project , you can set the project to disallow public fork. I assume that they will fork the project and it will be hidden. That said, they will be able to issue pull request and edit their own repository. It looks quite akward but it should work.
I don't have the feeling that there is a good way to handle permissions on github/bitbucket and so on.
edit
Not really a solution to enforce it but still quite valid. Since approval of pull-request is quite optional. Doesn't mean that you're screwed and in fact, if I were you. I wouldn't try to enforce a system. The reality is that code review is important. Pull request makes it easier to review sets of commits.
I worked many months being the only one in my team to create/approve pull requests. The team in which I worked decided that pull requests was a waste of time and I guess that none of them did code review until I left. Last thing I heard is that my team mate is currently refactoring my code because he has no idea how it works.
What I'm trying to say is that code review shouldn't be enforced and your team should see it as a quite important thing to do. Each member of your team should work together and code review each others on their own. By doing code review, they will have the right to deny code that they feel is "ugly" or should be designed in a different way. Each member get to stay updated on what other devs are working and may not have much problem switching on anybody's work in case of illness, departure or death!
Enforcing the process in the system could be good from a manager's point of view. But I believe that having approval as optional isn't bad either. And then, the manager's job will be to check the merged pull request for the pull request with 1 or less approved person. Check who merged the pull request and who approved. Find someone to review the code anyway.
On the other hand, if a pull request is hanging around forever and nobody is reviewing it. It's the dev task to ask a mate to review it.
I have a custom field called "Detailed Status" in the issue page. After an issue is verified by testers, they will change the value of this field to "Ready for Deployment". After we deploy the latest code to the server, this should be changed to "Verified after Deployment".
At the moment, after every deployment there will be at least 10-15 issues which will require a developer to manually go to each issue and change the value of the custom field to "Verified After Deployment"
Is there a way I could automate this?
I went through the documentation - I found out the option to do a Bulk Edit but my project architect wouldn't hear of any manual intervention at all.
Event listeners wouldn't serve the purpose would they, since deployment is not a Jira event but an external process. Could this be done using a script ? By directly doing an update on the JIRA tables or so ?
Sorry for sounding very vague and ignorant, since I am quite new to JIRA customization. Any pointers would be appreciated. Thanks.
There is a REST API that can be used by a script to update the custom field in the issues.
Start with http://jira-python.readthedocs.org/en/latest/
or
https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Edit+issues#JIRARESTAPIExample-Editissues-Examplesofupdatinganissueusingfields.
Sounds like your QA takes action during the Dev process (on Dev/Test/Stage environment(s)) to verify the issue has been resolved, and again after the deployment to a Production environment. If this is true, you could modify your workflow to allow for status & transitions to automatically set the field via a Post Function.
If QA hits 'Pass', it sends the issue forward in the workflow where that action updates the field "Detailed Status", and if they hit 'Fail/Reopen' it sends it back to Dev along with the corresponding status you want on that custom field. This would meet the mandate of no manual intervention.
There are several free plugins that can accomplish this, and streamline your workflow so that it mirrors your development practices.
I'm wondering if there's a way to write a tfs query such that when the results change, I will receive an email notifying me.
side question - is there a way to subscribe to updates to specific pieces of code?
Thanks!
I have the TFS Power Tools installed. The Alerts Explorer appears to have pre-configured alerts for several check-in activities. One of them is Check-In of a specific file happens.
And, I'm not sure which results you're talking about, but... You can also create various alerts for Builds and Work Item actions. I've got mine set up to alert me when something is assigned to me or when something assigned to me changes.