Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
SYS-CON.TV

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
Efficiency in Development Workflows: Pull Requests and Code Review
We talk about the steps necessary to get your feature shipped: Pull Request, Code Review and Merging

This is a republished blog post. You can find the original source here: http://blog.codeship.io/2013/08/22/the-codeship-workflow-part-2-pull-requests-and-code-review.html

Using Pull Requests
As I mentioned last week we use GitHub Flow on GitHub. But the whole workflow we describe is also possible when working with BitBucket. We do not have a policy when a pull request should be opened. Some of our developers open them when they start a feature, some wait until the feature is implemented. Then we push regularly to that branch as explained in the last post.

Open pull requests are helpful as everyone can see what we are working on. One really important part of feature branches and pull requests are proper commit messages.

The Codeship Workflow - Pull Requests

Writing good commit messages
As a distributed version control system, git makes it easy to take large changes and split them into small commits. Then these commits have a descriptive message with a short explanation in the first line and, if necessary, a longer description after a separation line. The git documentation project has some nice guidelines on it. Giving every commit a proper message and splitting large changes into a number of small commits makes your code history easier to read. It will be easier for your teammates to understand the history of your code.

I personally prefer git-gui for commiting and splitting up commits. It does only this job, but it does it very well. Take a look at some of the other git tools we like at the end of the post.

Using GitHub Issues and Labels
Once the feature is ready to be reviewed we assign its pull request to somebody else on the team. you have to read through the changes on GitHub at least once before handing the pull request . Making sure no obvious errors are in the code reduces the time and cycles necessary for a good code review. It is very helpful to inspect the changes outside of your own editor and with the excellent GitHub comparison view.

The Codeship Workflow - Comparison View

Now that we assigned the pull request, somebody on our team has a GitHub issue with his name attached. This way anybody can easily filter out the pull requests they need to look through. Now the last step is labeling the pull request with needs review. This way the reviewer knows this pull request is finally ready to reviewed.

The Codeship Workflow - GitHub Issues

When starting a pull request, the developer and reviewer can decide on looking through the pull request together or not. Especially for large changes reviewing the code as a pair is great.

Then we review the structure and syntax of the code, but we currently do not review the functionality itself. Before implementing a feature we discuss it in detail, so there is a common understanding. Once the feature is implemented, we trust our engineers that it does what it should. We are not working with a staging system.

One improvement we are starting with now is functional reviews for large and public facing features. Just so a second pair of eyes looks at changes that possibly impact a lot of our users. But this is still not a strict part of our workflow. A developer may request it after the implementation or we plan it before we start working on it.

When the review is done it either gets merged or, if the reviewer leaves comments, the GitHub issue is labeled as reviewed. This way developers can take a look at their open issues and see which have been reviewed and which need more attention.

The feature is ready to be merged as soon as the developer either updates the pull request or explains why she did it differently.

There's one challenge with every release workflow that involves code reviews: Getting the team to review as fast as possible without interrupting their work. We try to do it asynchronously for smaller features and sitting down for shared code review on larger features. This is no silver bullet, but in our experience it works well.

GitHub Merge Button
To make sure nobody introduces changes into our production system without review, we have a strict rule that you can never merge your own code. This rule is not enforced through technology, but a strict team policy.

The only exceptions are scheduled releases, for example a maintenance Deployment. Then we let somebody review the changes and leave a ready to be merged comment. The build can then be merged whenever the developer wants.

By releasing through the GitHub merge button everyone on the team can push to production. Making this possible for every developer or designer in our team is very valuable. It allows everyone to take part in the process and it speeds up our daily work.

The Codeship Workflow - GitHub Merge Button

As soon as we hit the merge button our tests are kicked off on the Codeship again and the deployment starts. Next time we will go into more detail about this part of our infrastructure, how we deploy to our staging app, test our migrations, build our deployment pipelines and then push to production several times a day.

Your Development Workflow
How are you working? We would love to hear about it in the comments. Let us know if you have any questions or suggestions to our workflow. Your feedback is always appreciated!

Ship long and prosper.

Further info

About Manuel Weiss
I am the cofounder of Codeship – a hosted Continuous Integration and Deployment platform for web applications. On the Codeship blog we love to write about Software Testing, Continuos Integration and Deployment. Also check out our weekly screencast series 'Testing Tuesday'!

Latest AJAXWorld RIA Stories
"We work around really protecting the confidentiality of information, and by doing so we've developed implementations of encryption through a patented process that is known as superencipherment," explained Richard Blech, CEO of Secure Channels Inc., in this SYS-CON.tv interview a...
"Our strategy is to focus on the hyperscale providers - AWS, Azure, and Google. Over the last year we saw that a lot of developers need to learn how to do their job in the cloud and we see this DevOps movement that we are catering to with our content," stated Alessandro Fasan, He...
Data is the fuel that drives the machine learning algorithmic engines and ultimately provides the business value. In his session at Cloud Expo, Ed Featherston, a director and senior enterprise architect at Collaborative Consulting, discussed the key considerations around qualit...
Andi Mann, Chief Technology Advocate at Splunk, is an accomplished digital business executive with extensive global expertise as a strategist, technologist, innovator, marketer, and communicator. For over 30 years across five continents, he has built success with Fortune 500 corp...
DXWorldEXPO LLC announced today that the upcoming DXWorldEXPO | CloudEXPO New York event will feature 10 companies from Poland to participate at the "Poland Digital Transformation Pavilion" on November 12-13, 2018.
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


SYS-CON Featured Whitepapers
ADS BY GOOGLE