Posted on Leave a comment

Setting Up A CI Laravel Pipeline Using Bitbucket

Continuous Integration

Is a must in today’s software architecture. Setting up a solid CI/CD pipeline will save you countless hours and money immediately and down the line.

There are plenty of tools that can accomplish your CI/CD goals from Jenkins, to CircleCI however in today’s tutorial I will be showing you how to accomplish this using Bitbucket pipelines.

Editing The YAML File

Bitbucket’s pipeline system uses yml files to spin up docker instances and run your scripts. This is an example file that runs composer, generates keys, runs migrations, installs passport and runs the tests. It also only runs when deploying to master branch and sets up a mysql instance and sets the environment keys.

# This is a sample build configuration for PHP.
# Check our guides at https://confluence.atlassian.com/x/e8YWN for more examples.
# Only use spaces to indent your .yml configuration.
# -----
# You can specify a custom docker image from Docker Hub as your build environment.
image: lorisleiva/laravel-docker
pipelines:
  branches:
    master:
      - step:
          caches:
            - composer
          script:
            - composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts
            - cp .env.example .env
            - php artisan key:generate
            - php artisan migrate
            - php artisan passport:install
            - vendor/bin/phpunit
          services:
            - mysql
      - step:
          name: Deploy to prod
          deployment: production
          # trigger: manual  # Uncomment to make this a manual deployment.
          script:
            - echo "Deploying to prod environment"
            - curl -X GET https://forge.laravel.com/servers/148653/sites/653797/deploy/http?token=4Q8e1kFPmFsHbxOBek7jcqikAvGVTbiX50tsPUPK
definitions:
    services:
      mysql:
        image: mysql:5.7
        variables:
          MYSQL_DATABASE: 'ben'
          MYSQL_RANDOM_ROOT_PASSWORD: 'yes'
          MYSQL_USER: 'homestead'
          MYSQL_PASSWORD: 'secret'

Why Is Continuous Integration Important?

I did an article about why continuous integration is important to the solo developer and I suggest everyone take a few moments and read that article. It outlines why having a solid CI/CD plan in your architecture, however the TL;DR is that is saves you time, money, effort and stress by spending the little bit of time up front to ensure you have tested and tried code before you ship to production.

Posted on 2 Comments

Why Continuous Integration Matters To The Solo App Developer

Your Continuous Integration Architecture Is Just As Important As Your Software Architecture

This is something that I learned when I was a senior software devops engineer at Apple (yes that is the exact title, it was a hybrid role). This was the first time that I was really introduced to the concept of continuous integration and I was amazed at how intricate and complex the setup at Apple was. When I left Apple in 2015 I had a thorough understanding of CI/CD and understood its importance, however I was convinced that it was really only useful and worthwhile to big corporations and I as a solo developer do not need to implement such pipelines into my small applications. I changed that mode of thinking a couple of years ago and today I will explain to you why it is important for you to implement CI in your projects as early as possible. Even simple apps such as this one has a basic CI/CD pipeline set up.

You Might Be Wondering…What Is Continuous Integration

For all my non devops folks reading this….which is most of you, you may be wondering what is continuous integration? Well here is one definition

Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control.

Definition of continuous integration provided by Microsoft

Basically it is your setup that prevents your production app from crashing and burning if you or a team member accidentally commits crap code. Usually it goes something like this: You push some code to master, you have a service (Jenkins for example) run some tests everytime new code is pushed to master. If the tests succeed, then pull the latest code on production server from master. If the tests fails, email whoever needs to be emailed (or Slack or pigeon carrier idc).

What Benefit Is It To A Solo Dev?

So you may be reading this and thinking the same thing I thought. This is awesome if you have a ton of developers working on code, but isn’t it overkill for just one person? I can just write and test the code myself? This is true that you CAN but think about this.

1) Save Time

Instead of manually running each test and wasting time waiting for output, you can delegate that busy work to your servers, those 30 sec – 5 min wait times for testing do add up over time. That’s time that can be used to build features.

2) Safely Scale Development

You may be a solo developer now, but perhaps you want to make your source code open source to allow more developers to help you out. Let’s say you end up getting 20 developers putting in weekly consistent work. With a solid continuous integration pipeline you can have them commit code, it runs the tests, merges into master and deployed to production without you having to manually approve and check each PR. This level of automation allows more time and resources to go into the actual application.

3) Keep A Clean Healthy Production App

If continuous integration is set up correctly then you should always have a clean solid production facing application. You can sleep easy at night knowing your app will never go down just because someone committed an extra semicolon or lack thereof.

If You Aren’t Using CI/CD You Are Setting Yourself Up For Failure

I use continuous integration in all of my personal projects/apps and if I am working on a client application and it doesn’t have CI, that is the first thing that I implement. Eventually sooner or later there will be bad code committed to your repository and if you are not setting up an apparatus to catch that, then it is only a matter of time before your application will crash in production for untested code. Don’t set yourself up for failure it’s much simpler and easier to set it up in the beginning of a project than at the middle or the end. Save yourself time, energy and money.