magallanes/CONTRIBUTING.md

Contributor guidelines for Magallanes

Welcome to Magallanes! We are much appreciated you've decided to contribute to this project! Please read the following guidelines to make your and our work easier and cleaner.

TL;DR

1. Write clean code with no mess left
2. Contribute the docs when adding configurable new feature
3. Create your pull request from develop branch
4. Ensure your code is fully covered by tests

---

Reporting issues

If you have a problem or you've noticed some bug, please feel free to open new issue. However please follow the rules below:

• First, make sure that similar/the same issue doesn't already exist
• If you've already found the solution of the problem you are about to report, please feel free to open a new pull request. Then follow the rules below in Developing Magallanes section.
• If you are able to, include some test cases or steps to reproduce the bug for us to examine the problem to reach the problem origin.

Opening pull requests

Pull Request are actually some kind of issues with code, so please follow the rules above in Reporting issues section before making the pull requests. Our code isn't so beautiful, tested and testable as we would like it to be but if you're pushing your code please be sure it meets the requirements from Organization and code quality chapter. We want to improve the existing code to facilitate extending it and making fixes quicker. So if you are editing some class and you find it ugly, please do not ignore it. Following The Boy Scout Rule - Leave the campground cleaner than you found it - we all can improve the existing code. Keep your git commits as atomic as possible. It brings better history description only by commit messages and allow us to eventually revert the single commits with no affects. Your commit messages should be also descriptive. The first line of commit should be short, try to limit it up to 50 characters. The messages should be written imperatively, like following:

Add MyCustomTask

If you need to write more about your tasks, please enter the description in the next lines. There you can write whatever you want, like why you made this commit and what it consists of.

Add MyCustomTask

This task has very important role for the project. I found this very useful for all developers. I think the deploy with it should be a lot easier.

Optionally you can tag your messages in square brackets. It can be issue number or simple flag. Examples:

[#183] Add new CONTRIBUTING document
[FIX] Set correct permissions on deploy stage
[FEATURE] Create new PermissionsTask

Remember of square brackets when adding issue number. If you'd forget adding them, your whole message will be a comment!

Contributing the documentation

Magallanes is made to deploy your application quick and with no need to write redudant code. Usage is as simple as writing the configuration for target project in YAML files. In the nearest future we would like to make some Wiki with all available options, tasks and commands. For now, the only "documentation" are example files in docs directory. If the code you are going to include in your pull requests adds or changes config options, please make sure that you create a new sample in those files. You should also do the same with commands.

Developing Magallanes

Branches

The flow is pretty simple. In most common cases we work on develop branch. It's a branch with the newest changes which sometimes need more testing. All pull requests are opened to be merged into that branch. That keeps us safe to not deploy unsafe code into production - master branch. When we decide that every changeset in develop is tested manually and works as it's intented, we merge it to master. If the change you commited is pretty hot and needs to be released ASAP, you are allowed to make a pull request to master branch. But it's the only case, please try to avoid it. All pull request that are not made on develop will be rejected. If you want to use develop branch in your code, simple pass dev-develop to dependency version in your composer.json file:

{
	"require": {
		"andres-montanez/magallanes": "dev-develop"
	}
}

Organization and code quality

We use PSR2 as PHP coding standard. Some of the rules we follow that are not included in document above:

• Variables' and properties' names are camelCased (e.g.: $thisIsMyVariable)
• Avoid too long or too short variables' and methods' names, like $thisIsMyAwesomeVariableAndImProudOfIt
• Names of your properties/methods should be intuitive and self-describing - that means your code should look like a book. Developers who read the code should immediately know what a variable includes or what a method does.
• Let your methods will be verbs. For boolean methods, prefix it with is, has, and so on. E.g.: isConfigurable, hasChildren.
• Be SOLID and follow KISS - let the class be responsible only for its tasks.
• Write testable code and if there's a need - easy extendible.
• Avoid duplications

The rules above have been set a long time after the project has started. If you notice some violations, please open a new issue or even pull request with fixes. It'll be much appreciated.

Tools you can use to ensure your code quality

1. PHP-CodeSniffer
2. PHP Mess Detector
3. PHP Copy/Paste Detector
4. PHP Dead Code Detector
5. PHP Coding Standards Fixer

Testing and quality

We use PHPUnit to test our code. The whole project is not covered with tests right now but we've been working on it for some time. If you want your code to be merged into Magallanes, we want you to push it with proper tests. We would love to reach and keep at least 90% of line code coverage. In short time we want to configure quality tools to make sure your code is tested properly with minimum coverage. Anyway, try to keep 100% of Code Coverage in your pull requests. To run your tests with code coverage report, you can either run it with:

bin/phpunit --coverage-text

or with more friendly and detailed user graphical representation, into HTML:

bin/phpunit --coverate-html report

where report is the directory where html report files shall be stored. Tests structure follow the same structure as production code with Test suffix in class and file name. All tests should go to tests directory in project root. So if you've created a class Mage\Tasks\BuilIn\NewTask the testing class should be called MageTest\Tasks\BuiltIn\NewTaskTest. To provide more strict tests, point what the method actually test and omit testing some classes indirectly, remember to add annotations to your tests:

• @coversDefaultClass class annotations This prevent to to write full class name each time you write @covers for test method (see next point)

/**
 * @coversDefaultClass Mage\Console\Colors
 */
class ColorsTest extends PHPUnit_Framework_TestCase
{

• @covers methods annotations

/**
 * @covers ::add
 */
public function testAddOnePlusOne()
{
	// ...
}

Note: If you omit coversDefaultClass for test class, you need to write full class name in @covers annotation.

Test class musn't test more than one class and any other classes than class being actually tested

Configuration

Magallanes configuration is kept in YAML files. Please follow those rules while adding or changing the configuration:

• Keep 2 spaces indentation in each level
• Multi-word config keys should be joined with dash (-), like my-custom-task
• If your contribution includes new config key, please be sure that you've documented it in configuration documentation.