Tag: packagist

6 tools I couldn’t live without

Posted on | by JohnoTheCoder | Leave a Comment on 6 tools I couldn’t live without

Hi everyone

So today I thought I would do a quick post, as it has now been just over a year since I started as the Senior Systems Architect at Speed Agency. We’ve had an amazing year, seeing the design, development, and delivery of a number of bespoke systems, including our own modular content management system. Of course, to achieve all this we use a whole bunch of tools. Here I thought I would summarise my favourite;

#1 Digital Ocean

Now, I know there are competitors out there, however I haven’t used them. The reasons I love Digital Ocean can be summarised here:

  • We run a very strict set of processes with regards to the deployment of changes to our live environment. The snapshot functionality means I can have a single (or multiple) staging environments built in next to no time
  • Their customer service is absolutely top
  • Their availability is high, and their prices very reasonable
  • The server monitoring is really pretty damn good, especially as it’s essentially a free extra
  • And all the usual stuff to do with Volumes, Floating IPs, etc.

More information about Digital Ocean

#2 Status Cake

I’ve used a number of different suites to monitor uptime, I’ve never found one which is better for configuration, server and website monitoring (amongst other things). Also, very very few false negatives – which are a nightmare to manage if you’re handling SLAs on uptime!

Track your uptime and server statuses with Status Cake

#3 Packagist

I’ve done a blog article on Packagist before, however I have to say I love it. The power of managing modular code and dependencies through Composer, added with the closed-source nature of private packagist is just great.

Find out about Packagist

#4 GitLab

We started using GitLab for managing issues and our Git repositories. I’ve got to say, whilst it might start to fall down against its Goliath-size counterparts (such as Atalassian’s BitBucket + Jira haymaker of a combo), it has lasted us very well, it’s a great system to have, it’s open source, easy to use (particularly if you’re familiar with GitHub) and has been a great toe-in-the-water for this style of project management.

Learn more about GitLab

#5 Confluence

I’m a true nerd for documentation. I love it. I mean I love it more than I love flow charts, which is really saying something. Confluence is phenomenal. For managing, exporting, modifying, discussing, sharing, and structuring your documentation this is the absolute bee’s knees. Seriously, if you need to document your source code, project paperwork, or anything in the software development arena, sign up for it, right now, don’t even hesitate.

I don’t know why you don’t already have Confluence

#6 draw.io

There is a standing joke in my office, in which I am referred to as Sheldon (though my computational personality tends to find me also referred to as Laurie Bream) – this is because of my absolute adoration for flow charts. From processes to systems designs to user-workflows I absolutely swear my draw.io, which allows you to draw these diagrams, export them as XML files for later, and export as a number of useful formats (PDF, for example).

Get your workflow on with draw.io

In Summary

Tools and software should make your life easier. The above 6 things have made my life infinitely easier, and helped me structure, grow, and enhance my team’s capacity and capability by providing smoother, more efficient processes and workflows. I can’t take all the credit, of course, all those tools were at some point referred to me by a colleague, friend, Search Engine, or somewhere; and none of them would have any effect if my team didn’t take the whole hearted approach to adopting the things that I have mentioned above. Every team has a critical mass which makes systems effective, and my team are the best at adapting to our ever changing requirements.

I’d love to hear what tools you have which make your job easier, I can’t promise I won’t think “oh, that’s a good idea!” and consequently adopt the tool myself 🙂

Until next time,
Johno

Edit: Considering this is essentially 6 links I thought I’d best state – there’s no commercial interest in this post, I’m in no way endorsed by those companies, have no affiliation, no referrer links or anything included!

Setting up Private Packagist & BitBucket or GitHub

Posted on | by JohnoTheCoder | 1 Comment on Setting up Private Packagist & BitBucket or GitHub

Hi all

This is a really quick tutorial, because frustratingly I couldn’t find one that offered me this quick guide that had an integrated approach to doing this.

I’m going to mostly cover the bits that I had to learn myself through Googling etc. in the hope that you won’t have to waste hours on Stack Overflow and so on trying to figure out how to get it working.

I’ve used composer a million times, but always as a consumer, not as a publisher. Least of all as a publisher on private packages.

This tutorial makes a couple of assumptions:

  1. You understand what Composer is and how it works
  2. You manage some private repositories and you’re dealing with private packagist for closed source code
  3. You have a basic understanding of what an SSH key is and how to generate one

Step #1 – Get signed up for a packagist.com account

The first thing you will need to do, if you’re using private packagist for your packages, is sign up for an account on packagist.com this will allow you to privately package your code using the usual composer method.

Don’t get confused between packagist.org (which is free and for open source stuff) and packagist.com which is private, and is paid for. Though you do get a free trial which is handy.

Step #2 – Allow access to your organisation/repository

Okay, this is the bit that annoyed me the most I think. BitBucket allow you to do stuff with organisation and app access and stuff.

Both BitBucket and GitHub allow you to grant access to private repositories via an SSH key. Private Packagist provide you with their SSH key, give this key access so that Packagist can access the repository to get the information from your composer.json file.

Step #3 – Generate an SSH key for your machine or server

I’m not going to explain how to do this. A quick google will reveal this, it’s well documented.

Step #4 – The gotcha, what to do with your SSH key

This is the bit that caused me some errors and got quite annoying. I usually use my various accounts to do my pulls, checkouts, etc. so I’ve not used my SSH key with my repositories.

Your SSH key must be allowed on both Packagist and your chosen repository provider (BitBucket or GitHub, usually).

What happens is, you fire off your Composer command. This goes to Packagist.com using your SSH key and will get the information it needs about the package, then it goes off to your repository to get the appropriate code. If you enable on Packagist and not your repository the require/install will fail. If you enable it on your repository and not on Packagist, it’ll tell you that your package wasn’t found.

Step #5 – Minimum Stability

This one is well documented, but still frustratingly buried within a pile of other documentation. There are a whole heap of tags and stuff that you can use, but ultimately the stability of a package is determined from the repository itself.

Learn about how Composer works with your repository here.

Let’s assume you couldn’t be bothered to read that, you just want a quick way to test that this is set up properly. Add a tag of v1.0.0 or whatever version number you’re using. It will assume this is a release and is consequently stable.

Summary

It’s actually remarkably easy getting this running. It’s just frustrating if, at the time like myself, you don’t know what you’re doing when it comes to creating packages, let alone managing closed source stuff through it.

Once it is running, however, it becomes beautiful. It’s a very elegant of managing dependencies, and keeping multiple sets of source code up to date. And for a very small price tag of about €14 per seat, per month; it’s definitely a cost saver. (Plus whatever you spend on repository hosting as well, of course).

I realise there are plenty of ways of hosting your repositories yourself, and of hosting your packages yourself too. This approach is more suited to companies whose development teams are too busy to want to manage this infrastructure; it’s, obviously, up to you to determine whether there’s enough value in managing this in-house, or whether it makes more sense, commercially, to pay a really small fee and not have to worry about it.