{"id":52,"date":"2019-04-02T16:53:59","date_gmt":"2019-04-02T16:53:59","guid":{"rendered":"https:\/\/serioussemicolons.wordpress.com\/?p=52"},"modified":"2019-04-02T16:53:59","modified_gmt":"2019-04-02T16:53:59","slug":"quick-tip-testing-feature-branches-with-composer","status":"publish","type":"post","link":"https:\/\/blog.bryant.ai\/?p=52","title":{"rendered":"Quick Tip: Testing Feature Branches with Composer"},"content":{"rendered":"\n

I was adding a new feature to my CakePHP SecureIDs Plugin<\/a> today and needed to test it against a living, breathing CakePHP app. Rather than spin up a brand-new one, I decided to use an existing app I had on hand for a contract I have open. Thing was, I didn’t want to go through the whole rigamarole of creating a release, pushing it, waiting for it to hit Packagist, waiting for Composer to see it, and only then<\/em> being able to add it as a dependency to my app.<\/p>\n\n\n\n

Composer is a smart tool, and so is git-flow<\/a>. Surely I can combine the two to bypass the above lengthy process and get testing faster, I thought. Turns out it’s totally possible, here’s how I did it in a few easy steps (I’ll go into greater detail in a minute):<\/p>\n\n\n\n

  1. Start a feature branch in the plugin repo<\/li>
  2. Push the feature branch to the remote<\/li>
  3. In the test app’s composer.json<\/code> add the repository the plugin sits in<\/li>
  4. Add the dependency with the version string dev-feature\/feature-name<\/code><\/li><\/ol>\n\n\n\n

    For what it’s worth, I didn’t think this was gonna work because I was sure Composer was gonna choke on the \/<\/code> in the branch name…but nope! Handled it just fine. \ud83d\udc4c<\/p>\n\n\n\n

    Breakdown<\/h2>\n\n\n\n

    So what does all this mean? In short, the steps above describe a way to short-circuit the package release process used in testing dependencies with Composer<\/a>. Normally it’s a lengthy process with lots of steps in between committing your code and actually seeing it work in a living-breathing app, but the process I described above is a better way if you’re just testing things or making temporary changes.<\/strong> Don’t use this process to release code into the wild, it’s not a good idea.<\/p>\n\n\n\n

    In order to use the steps above, your repo must be git-flow<\/a> enabled. Git flow is a very powerful tool that I’ve used for years to keep my development process sane and well-organized, especially when working in teams. I don’t have time to evangelize GF properly here, so I’ll leave that up to some other qualified individuals:<\/p>\n\n\n\n