#styleci | Explore Tumblr posts and blogs

mlbors · 8 years ago

Text

First steps with continuous integration

In this post, we are going to overview some tools to use continuous integration.

Continuous integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. CI originated from within the extreme programming paradigm, but the principles can be applied to any iterative programming model, such as agile programming.

There are many tools that we can use and one of the most famous is probably Jenkins, written in Java. But we are not going to talk about Jenkins in this post. Instead, we are going to generate a really small project with some other tools. For that, we need Git, Ruby, PHP, Composer, PHPUnit, PHP-CS-Fixer, GitHub, Travis, StyleCI and Codecov. We may think that is a lot of stuff, but there is no reason to be afraid.

Definitions

First of all, a few and short definitions!

Git

Git is a free and open source distributed version software for tracking changes in computer files and coordinating work on those files among multiple people. It was created by Linus Torvalds.

GitHub

GitHub is a web-based Git that got a mascot called Octocat, a cat with five tentacles and a human-like face. It was created by Chris Wanstrath, PJ Hyett and Tom Preston-Werner.

Ruby

A famous programming language. We will need it to install gems (Ruby Libraries).

PHP

Another famous programming language. We will create our project with it.

Composer

A dependency manager for PHP that was initially developed by Nils Adermann and Jordi Boggiano.

PHPUnit

A framework for unit testing for PHP created by Sebastian Bergmann.

PHP-CS-Fixer

A tool to automatically fix PHP coding standards issues.

Travis CI

A continuous integration service used to build and test software projects hosted at GitHub.

StyleCI

StyleCI makes sure that all code on our PHP project is written to a consistent standard.

Codecov

Codecov provides metrics and insights into the results of tests through code coverage.

For the sake of this article, we are not going to discuss here about test driven development (TDD), how to write good and efficient tests and things like that. These are other subjects. The aim of this post is to see how to install and use all of those tools.

Installation

Composer

Installing Composer is really easy. We just have to go to https://getcomposer.org/download/ and follow the instructions. On Windows, there is an installer.

PHPUnit

Again, we have to go to https://phpunit.de/manual/current/en/installation.html and follow the instructions. On Windows, globally install PHPUnit is a bit trickier.

Ruby

On a Linux system and on macOS, Ruby is already here. On Windows, we have to download the installer from https://rubyinstaller.org/downloads/.

Git

We just need to go here https://git-scm.com/downloads and follow the instructions.

PHP-CS-Fixer

On a Linux system and on macOS, we can globally install PHP-CS-Fixer by following the instructions written here https://github.com/FriendsOfPHP/PHP-CS-Fixer.

GitHub, Travis CI, StyleCI, Codecov

We just have to go on GitHub (https://github.com/) and create an account. We will then have access to Travis CI (https://travis-ci.org/), StyleCI (https://styleci.io/) and Codecov (https://codecov.io) with that same account.

Travis gem

The gem can be install by doing the following command in the terminal:

gem install travis

Setting up the project

Now that we have all our new tools, we can move to the next step and set up our project.

Composer

The first thing we need to do is to create a composer.json file at the root of our project. We can create it manually or by doing the following command:

composer init

Command

{ "name": "mlbors/simple-travis-codevoc-styleci", "description": "Simple project using Composer, PHPUnit, Travis, Codecov, PHP-CS-Fixer and StyleCI", "license": "MIT", "require": { "php": ">=5.6", "ext-curl": "*", "friendsofphp/php-cs-fixer": "2.0.0" }, "require-dev": { "phpunit/phpunit": "5.7.*", "vlucas/phpdotenv": "^2.0" }, "autoload": { "psr-4": { "mlbors\\SimpleApp\\": "app/" } }, "autoload-dev": { "psr-4": { "mlbors\\SimpleApp\\Tests\\": "tests/" } }, "homepage": "https://github.com/mlbors/simple-travis-codevoc-styleci", "authors": [ { "name": "mlbors", "email": "[email protected]", "homepage": "http://www.mlbors.com/" } ] }

composer.json file

In the above example, in the require section, we say that we need PHP 5.6 or higher, Curl and PHP-CS-Fixer. In require-dev, we have PHPUnit and PHPDotEnv. In the autoload and autoload-dev sections, we say that we use the PSR-4 standard and how our namespaces will be.

It is time to do the following commands to install and generate the autoload:

composer install composer dump‑autoload -o

GitHub

First of all, we create two files: .gitignore and .gitattributes.

/vendor /node_modules .env .php_cs.cache composer.lock npm-debug.log

.gitignore file

/.gitattributes export-ignore /.gitignore export-ignore /phpunit.xml export-ignore /.env export-ignore /.env.example export-ignore

.gitattributes file

Then, we go on GitHub and create a new repository. Then, on our system, at the root of our project, we do the following commands:

git init git add . git commit –m "First commit" git remote add origin https://github.com/user/repository.git git push –u origin master

Replace user and repository by your username and your repository

Now we can go on Travis CI, StyleCI and Codecov and link our repository to those services.

StyleCI

Now, at the root of our project, we create the styleci.yml that will tell StyleCI file which rules we use.

preset: psr1

.styleci.yml file

.env File

The .env file allows us to place some values that we do not want to appear in our code. In our example, we can load them with PHPDotEnv. The .env file will be ignored by Git but we can create a .envexample file with fake values just to tell the world that we need a .env file.

SIMPLE_KEY="someValue"

.env file

Travis CI

Now we can create the .travis file that will tell Travis CI what to do with our files. We can also include critical values in that file, for example, the ones that are in the .env file, by encrypting them like so:

travis encrypt SOMEVAR=secretvalue

Command

language: php php: - 5.6 - 7.0 install: - sudo pip install codecov before_script: - composer self-update - composer install --no-interaction after_success: - bash <(curl -s https://codecov.io/bash) script: - vendor/bin/phpunit --coverage-clover=coverage.xml env: - SIMPLE_KEY=someValue notifications: email: false

.travis file

In the above example, we tell Travis CI a few things: we state that we use PHP and our app will have to work on PHP 5.6 and PHP 7. We also install the Python codecov package with pip for code coverage. Our dependencies will also be installed with Composer and PHPUnit will be executed. If everything is alright, we send the information to Codecov.

More information about how to customize the build are available here!

PHP-CS-Fixer

The .php_cs file tells PHP-CS-Fixer the rules that we use.

notPath('vendor') ->in(__DIR__) ->name('*.php') ->ignoreDotFiles(true) ->ignoreVCS(true); $rules = [ '@Symfony' => true ]; return PhpCsFixer\Config::create() ->setRules($rules) ->setFinder($finder) ->setUsingCache(false);

.php_cs file

PHPUnit

We create a phpunit.xml to tell PHPUnit how to run our unit tests. We also set the processUncoveredFilesFromWhitelist attribute for code coverage.

<?xml version="1.0" encoding="UTF-8"?> <phpunit backupGlobals="false" backupStaticAttributes="false" bootstrap="vendor/autoload.php" colors="true" convertErrorsToExceptions="true" convertNoticesToExceptions="true" convertWarningsToExceptions="true" processIsolation="false" stopOnFailure="false" syntaxCheck="false"> <testsuites> <testsuite name="SimpleApp Test Suite"> <directory suffix="Test.php">./tests/</directory> </testsuite> </testsuites> <filter> <whitelist processUncoveredFilesFromWhitelist="true"> <directory suffix=".php">./app</directory> </whitelist> </filter> </phpunit>

.phpunit.xml

In the above example, among other things, we tell PHPUnit where our test suite will be and how to compute the code coverage.

README

The README.md file tells the world about our project. We can also include into it the badges that Travis CI, StyleCI and Codecov will generate.

[![Build Status](https://travis-ci.org/mlbors/simple-travis-codevoc-styleci.svg?branch=master)](https://travis-ci.org/mlbors/simple-travis-codevoc-styleci) [![StyleCI](https://styleci.io/repos/75407002/shield?branch=master)](https://styleci.io/repos/75407002) [![codecov](https://codecov.io/gh/mlbors/simple-travis-codevoc-styleci/branch/master/graph/badge.svg)](https://codecov.io/gh/mlbors/simple-travis-codevoc-styleci) Simple project using Composer, PHPUnit, Travis, Codecov, PHP-CS-Fixer and StyleCI

.README.md file

Let's use all those tools

PHP-CS-Fixer

To use PHP-CS-Fixer, we can enter the following commands in our terminal:

$ php php-cs-fixer.phar fix /complete/path/to/dir $ php php-cs-fixer.phar fix /complete/path/to/file

On Windows we can do it like so:

php path\to\project\vendor\friendsofphp\php-cs-fixer\php-cs-fixer fix path\to\fileordir

PHPUnit

To run our tests, we just have to use

phpunit

On Windows, we can do it like so:

php path\to\project\vendor\phpunit\phpunit\phpunit

And we push

It is time! Now we can do

git add . git commit –m "This is a commit" git push origin mybranch

If everything is alright, our files will be send to GitHub, then to Travis CI and StyleCI. Travis CI will do what we wrote in our .travis file then send coverage information to Codecov. And voilà!

Advantages

Continuous integration advantages are several:

Integration bugs are detected early and are easy to track down

Constant availability of a "current" build for testing, demo, or release purposes

Frequent code check-in pushes developers to create modular, less complex code

Enforces discipline of frequent automated testing

Immediate feedback on system-wide impact of local changes

And so on. On the other hand, we can state that continuous integration requires a considerable amount of work and time. And 100% code coverage doesn't mean that every execution path is tested and our software is bug free.

You can find the complete example on my GitHub (https://github.com/mlbors/simple-travis-codevoc-styleci).

#ci #travisci #codecov #styleci #git #github #composer #phpunit #php #unit testing #continuous integration

0 notes

mbaljeetsingh · 8 years ago

Text

Tips For Building Your First Laravel Package

Laravel is a powerful and modern framework. It has tons of different features, which make our work faster and easier. But you can’t push everything into the single box. At one time or another, we’ve all been in need of something not implemented in the framework out of the box. So, you’re writing code by yourself; it works, and you are happy. Yep?

But what if you need the same functionality in another project? Will you write it again? Copy-paste it? Both solutions are bad because you’re solving the same problem again and again. And what about bugs? Imagine finding a bug in that code a few days later. Now you have to fix it in N places. Ufff, not fun!

A package can be a solution. Write your code once and use it in any number of projects. Maybe you found a bug, or want to make some changes? Do it just once in your package code and then pull required changes in all of your projects. Sounds good?

The First Step

Before diving into the work with your head, check Packagist first. It is possible someone has already solved your problem. If you can’t find an existing package, try to explore the question a little bit deeper. Maybe you’re not using the most accurate keywords in your search. Don’t be afraid to spend another 30 minutes; it could save you 30 days eventually.

Development

You’ve searched, but no luck and now you’re willing to create a new Laravel package. What are the next steps?

First of all, take a look at the Laravel documentation. The Package Development page is a great starting point. You’ll find out in most cases, the heart of your package would be a service provider. Here you can register event listeners, middleware, routes, translations, views, etc. Maybe your package has its own config file, maybe even its own database migrations. You have to describe all of that in your service provider. It is the connection point between your package and Laravel.

Your head is full of knowledge; you are creating new GitHub repo and starting to write code. Great! What tips can I give to you?

I think one of the most important things, when you’re writing a framework package is to make the package close to the framework. In everything: architecture, naming, code style, documentation, every aspect of it. It will be much easier for people to understand and use your package if it looks like the part of the framework. But, it’s not always easy to choose those best names for classes, methods, variables, etc. I really like Jeffrey Way’s method, which I learned at Laracasts. When you’re feeling a name isn’t very good, delete it and write it as you’d want it to be in a perfect world, then use it. Simple enough, but it works. Naming is not the easiest thing in programming, and there are a lot of good books about it.

I’ve received the following feedback from someone using my package: “Nice readme file! It’s really easy to read it, it feels like I’m reading one of the Laravel docs!” That was my victory!

If people feel your package is a natural part of the framework — you’re on the right path.

Testing

Package testing can be really tricky. And the first question I had, before even starting to write tests was this: how should I test it? Should I create a new instance of my Laravel project, install my package there, and write my tests? These were the real usage conditions of my package, but my tests would be located outside of the package, which is really bad.

Luckily, there is Testbench Component to solve that problem. It provides a way to test your package without a standalone Laravel install. You can easily register your package service provider, aliases, set up the database, load migrations, etc.

The great thing about open source is you can use cool GitHub integrations for free. They can help you in different ways. My favorites are:

SensioLabs Insight – for code quality;

StyleCI – for code style;

Travis – for running tests automatically;

Coveralls – for measuring code coverage by tests;

Documentation

Your code is ready and, your tests are green. You think you’re done at this point? Nope.

Don’t be lazy; create a nice readme file. It can be really useful for you because you’re taking another look at your package in general. There have been so many times while writing a readme file that new ideas have come to me. And having a good readme allows others to be able to use your package as well. Isn’t it great to know your code is useful for someone?

I think a readme file is really important, and it should be as simple as possible. Use images, where possible. They are easier to understand. Write your documentation as close to Laravel Documentation as you can.

There is a really great article “How to write a readme that rocks“, take a look! There are a lot of cool tips and tools described there. For example, Michael Dyrynda’s Readme Generator, Grammarly, Hemingway App, etc.

Release

Don’t forget to add your package to Packagist, so it will be available through Composer. That will make your package installation really easy, and make it searchable through Composer. Use keywords in your composer.json file. You can also set up GitHub Topics to make your package even more searchable.

Use GitHub Releases for your package. Read and follow Semantic Versioning rules.

It doesn’t matter how cool is your package if people don’t know about it. Tell them!

Write short notes on community forums, for example, Laracasts Forum, Larachat, etc. Add a link to your package on Laravel News. Don’t be afraid to tell!

Conclusion

Creating your own packages can make your code cleaner, preventing you from repeating yourself over and over in different projects. I’m not saying you have to extract everything into the packages, no. It’s all about the balance, like in coding. Should I extract that code into the separate method? Or, maybe even into the separate class? Remember those questions? I think “Should I extract that code into the separate package?” is something similar to these questions. It depends. Feel it, and make a decision according to your context and experience.

There are a lot of aspects, which are not covered in this short article, but I really hope it will be useful for someone. Please, contact me if you have any thoughts or questions.

Wish you tons of stars on your own packages!

via Laravel News http://ift.tt/2kQczRF

#IFTTT #Feedly

0 notes