Looking to know if there is any way, that I can add gatekeeping rules to prevent code from getting checked in until there is atleast 1 approval on the CL?
I am not looking to add locks, as that prevents anyone from doing code changes.
The standard solution is to use Swarm (a free tool that integrates with Perforce) for code reviews:
https://www.perforce.com/manuals/swarm/Content/Swarm/home-swarm.html
Swarm tracks reviews of shelved changelists, and comes bundled with pre-submit triggers that block submit until the changelist has been approved.
Related
I am currently developing a website using html, css, php, and javascript. During this development, I am constantly modifying the css to get just the right look.
I feel that it is impractical to re-upload files or modify them all on GitHub as I continue this development. Am I right that I think that GitHub should be used near the ending stages of development, or is there some functionality of GitHub I do not yet know?
Github (and git in general) can be helpful in the development of a website, but it really depends on your needs. In your case, you mention CSS. If you manage to ruin your CSS beyond repair, then git has your back, since you can revert back to a working version. Github makes this easier by allowing you to directly see the CSS file with all insertions and deletions.
If your content does not undergo drastic changes, and you make occasional smaller changes, then git should work well. Version control is the main goal of git, and since small changes to a file don't involve a brand new copy of the file but rather the inserted and deleted lines, there may be an advantage to using git rather than backing up your entire website every now and then.
So in the end, it depends on what your website is like and how you plan to tweak/update it.
I see no reason why it should not be. The so-called development stage of any project is (should be?) especially messy. Although the benefits of version control is not apparent during this stage, they can not be stressed enough because of its ability
to "go back" in time,
to provide a sensible, repeatable, dependable work environment
to lead into a development process that you can rely upon.
A branching model is also required. This, coupled with a quick and easy devops procedure (which works so well with git) should also be employed from day 1.
When I did my website development, I used git extensively (although not GitHub), and since GitHub has excellent support for private repos, there is no reason not to use it. You could also take a look at GitHub Pages which creates websites from your repos!
I'm using Perforce version control system (http://www.perforce.com/) and would like to format source code files (mainly XML) when developers submit their files to Perforce. I know that Git and SVN allow script hooks that provide for that.
Is there a way to change files that are being submitted to Perforce using some kind of a hook?
How can I do that on Perforce?
Thanks!
When I've done these sorts of policy-enforcement tools in the past, I've done it post-commit.
That is, after the submit completes, my tool retrieves the newly-submitted files, re-formats them according to the policy that I'm enforcing, and submits the re-formatted files as a follow-on change.
I do this by writing a tool that monitors changes similarly to the way the change review daemon monitors changes, so that the tool notices new submits and reviews the new files to see if they comply to the organization policy.
I generally have the tool perform a "revert -a" prior to the submit, so that if the files were formatted according to policy by the original developer, no second submission occurs.
I actually think this is a better approach than trying to do it during the submit:
The change that is submitted is exactly as the user provided it, with the identical content as provided by the user
The modifications that are due to the tool are clearly visible in a separate submission, which makes it very easy to recognize when the tool has gone astray and damaged the file during its re-formatting (such tool bugs do occur).
The net effect, overall, is the desired one: the files at the head of the branch are formatted according to company policy.
A Perforce trigger is what you need.
The problem i am trying to solve is where developers change files without going through the proper channels. The developer should be able to make the change himself but only after his work was approved, since the code is used in a lot of projects
I found this link that also describes my problem:
http://www.p4ideax.com/ideas/694/temporary-permissions
One way to do it is to have only the architects have access to the files and then granting the developer temporary access. Maybe the permission can be linked to a specific job in perforce. The only way i can see how to do that is by adding the files that the person should be able to change to a new field in the jobs template ( done by architect ). Then have a server app dynamically call p4 protect and manage the permissions table. Then when the job is closed the permission is revoked. The server app could be the bugtracker software.
Is there an easier way or even 3rd party software out there that can solve the problem?
I know that another way to solve it is to put these sensitive files in a branch and then only allow the architects permission to merge into this branch. This solution feels a bit heavy handed.
Any suggestions would be helpfull
This is something that could certainly be done with a pre-submit hook. There are examples at Perforce Depot.
My thinking would be to reject submits for files in that section of the depot that didn't have a job that was on the "approved list". You could create the approved list in a number of ways, although a simple one (if you're using Perforce globally) would be to put the job list into a file under repository control and then have that list be available only to the architects.
The pre-submit trigger would then basically need to:
- If the files being submitted aren't in the protected tree, let the submit happen
- Grab an r/o copy of the file from the depot
- Grab the job list from the submit
- grep the job against the list
- If the job is in the list, let the submit happen
- Reject the submit with an appropriate error message
My team recently switched to all three technologies in the past several months and have worked hard to get it up and running. Next step is automating our changelogs. We have JIRA set up look for the tags (ex. TAG-123) in github commit messages. Jenkins monitors the GitHub commits on a 5 minute timer, pulls, builds, etc.
What I would like to see is a changelog generated automatically when a build is marked as "Promoted to Production." I would like to see it do something akin to the following:
Query Jenkins for the previous build marked as a production release and get the corresponding git commit SHA1.
Run a diff in between the current Git commit and the previous commit
Find all JIRA tickets that are referenced
Compile a list of JIRA titles
Have list export to a text file and placed in build drop (bonus if it can be accessed directly through Jenkins as well)
Whether this flow is followed as written or not is irrelevant--I'm after the end result and am not looking to re-invent the wheel.. Surely somebody done something like this before?
As far as reinvention goes, I was able to find https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin which allows somebody to piggy-back on the Promote to Production action and run a separate script. It would then be a matter of gathering functionality to accomplish the above. (I also noticed Jenkins can tag the current GitHub commit, which my team would likely do in addition.)
Anything closer to accomplishing this would be greatly appreciated.
Thank you!
Since nobody on our team had excess time to devote to this, we ended up throwing together a quick solution.
The Process
Install and setup the All Changes plugin for Jenkins.
When we release, we use "build promotion" system which puts stars next to the previous build, so we can easily see the build# looking at the history.
Copy and paste the relevant output from All Changes into something like notepad++ (human-diff'ing ftw!)
Run a regex find/replace. Search on the regex string, replace with an empty string. (below -- there's the big-bang option or its broken up for understandability.)
Manually organize and release in whatever form is the current agreed up standard.
Everything at once
(\s*\(commit:\s[a-z0-9]{40}.\s..detail)|([\r][\n]#.*\B[\r][\n][\r][\n])|(^[ \t]*)
Remove commit hash\s*\(commit:\s[a-z0-9]{40}.\s..detail
Remove time and surrounding line breaks[\r][\n]#.*\B[\r][\n][\r][\n]
Removing leading whitespace: ^[ \t]*
The Analysis
Pros:
Effective overall
Relatively quick to implement
Cons:
Not fully automated.
Need to revert to commit id if you release from multiple Jenkins jobs.
All Changes history only appears to go back as far as the Jenkins job (I could be mistaken about the specifics of this--I just remember minor grievances with something like this at one point.)
As a whole, the cons are somewhat "the nature of the beast." I'd love to read some other solutions. (For when we have that elusive thing called Time, of course!)
Alternative to dependancy on issue trackers could be to purely use the pull requests themselves. For us they had enough context to generate release notes and we used labels for categorisation. I created PullRequestReleaseNotes and you can try it. It supports GitHub, GitLab, BitBucket and TFS and it can generate release notes in markdown from merged pull requests and its labels and optionally post it to an Atlassian Confluence page and post it to a Slack channel as a post. It can be run as part of continuous integration. Here is a sample:
1.2.1 (MASTER) - XX XXX 2016
Enhancements
Category A
Awesome new feature #1854
Fixes
Category Z
Fixed problem with widget #1792
Category Y
Fixed problem with widget #1792
Fixed exception with view layout #1848
Eric suggests that you read your team's diffs every morning. Can I get TFS to automate this in some way? Ideally I'd like an email with all of the differences in, but I'd settle for a link to each of the commits.
As someone who works for Eric and who has the behaviour of checking the diffs each morning let me explain what I do. I'd like to think that I was one of the people he was thinking about when he wrote the post, but I know for a fact that he didn't know I did the diff checking each morning :-)
In Eclipse I use the Team, Synchronize... functionality to compare my local workspace with the latest on the server. As I do a get latest frequently, this tells me what has happened since I last did this (i.e. what changed while I wasn't looking).
In Visual Studio, I can do a similar thing by right clicking on the root folder of the area that interests me and selecting Compare... and then doing a compare of the Workspace version with the latest version.
Alternatively, you can just do a "History..." on the folder that is of interest and a brief scan down the history view will show you what has been happening and you can go look at what is interesting. It also encourages you to leave good check-in comments, and to encourage your developers to do the same :-)
I used to have email alerts configured for each check-in (Team, Project Alerts...), but I just ended up ignoring them most of the time. I even have a robotic rabbit configured to talk to me when someone does a check-in or runs a build - but this is only useful during the day, not checking what has happened the previous day while I was asleep (I live in a different time-zone to the rest of my colleagues so they do a lot of work while I sleep and vice-versa, making the practise of diff-checking even more useful)
In theory it would be possible to write a program that did generate you a diff each day between the latest version and your workspace version, however I've never bothered myself. This is partly because as I find the most value of the practise comes in exploring the changes that were made each day rather than just reading about them. I also admit that I wasn't aware that anyone else in the world was doing this daily diff routine - I figured I was alone in my code voyerisum, but obviously not!
UPDATE Feb 12, 2009: The following blog post just came to my attention.
http://blogs.msdn.com/abhinaba/archive/2008/07/07/auto-generating-code-review-email-for-tfs.aspx
It talks about (and provides source for) a tool called CRMail that will generate an email from a shelveset that will contain links back to Team System Web Access to show the diffs for each change in the changeset. It would be possible to modify this source to get it to show you diffs between changesets if you wanted to. Then you would just need to hook it up to run either as a nightly scheduled task or on every check-in by subscribing to the check-in event from TFS.
Have you explored setting up a report on the project portal that would show diffs based on date? I haven't done this (and I'm at home now so I can't investigate it), but I know that there is a lot of information you can get out of the portal. Whether you can get code diffs, I don't know.
The other alternative would be automating something with tfsadmin or the power tools. Again, not at work so I can't look at it, though the power tools seem like they may make it possible to do what you want from the docs.
A quick solution would be to configure project alerts to send you one email per changeset.
Filter these into a separate folder in your email client, and review them at your leisure.