<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: James Turnbull</title>
    <description>The latest articles on DEV Community by James Turnbull (@jamtur01).</description>
    <link>https://dev.to/jamtur01</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F154283%2Fbe92aec7-f952-46c7-99f1-d859dc692cf1.jpeg</url>
      <title>DEV Community: James Turnbull</title>
      <link>https://dev.to/jamtur01</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/jamtur01"/>
    <language>en</language>
    <item>
      <title>Adding a Remix on Glitch button to your GitHub project</title>
      <dc:creator>James Turnbull</dc:creator>
      <pubDate>Wed, 05 Feb 2020 17:57:10 +0000</pubDate>
      <link>https://dev.to/glitch/adding-a-remix-on-glitch-button-to-your-github-project-515c</link>
      <guid>https://dev.to/glitch/adding-a-remix-on-glitch-button-to-your-github-project-515c</guid>
      <description>&lt;p&gt;Seen those cool buttons that allow your GitHub project to run on &lt;a href="http://glitch.com?utm_medium=weblink&amp;amp;utm_source=dev.to&amp;amp;utm_campaign=blog&amp;amp;utm_content=dev"&gt;Glitch&lt;/a&gt;? They let people &lt;a href="https://glitch.com/help/remix/?utm_medium=weblink&amp;amp;utm_source=dev.to&amp;amp;utm_campaign=blog&amp;amp;utm_content=dev"&gt;remix&lt;/a&gt; your project as a Glitch application and work with it immediately. Making your own projects available on Glitch is super simple. To help, Glitch provides an &lt;a href="https://glitch.com/~github-import?utm_medium=weblink&amp;amp;utm_source=dev.to&amp;amp;utm_campaign=blog&amp;amp;utm_content=dev"&gt;app you can use to create your own Remix on Glitch button&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://glitch.com/edit/#!/import/github/glitchdotcom/starter-discord" rel="noopener noreferrer"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fcdn.glitch.com%2F2703baf2-b643-4da7-ab91-7ee2a2d00b5b%252Fremix-button.svg" alt="Remix on Glitch"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Let's create a button for &lt;a href="https://glitch.com/culture/discord-bot-starter-making-your-first-bot-easy/?utm_medium=weblink&amp;amp;utm_source=dev.to&amp;amp;utm_campaign=blog&amp;amp;utm_content=dev"&gt;Glitch's Discord bot starter kit&lt;/a&gt;. We open up the &lt;a href="https://github-import.glitch.me/" rel="noopener noreferrer"&gt;Remix on Glitch button app&lt;/a&gt;.&lt;/p&gt;


&lt;div class="glitch-embed-wrap"&gt;
  &lt;iframe src="https://glitch.com/embed/#!/embed/github-import?previewSize=100&amp;amp;path=index.html" alt="github-import on glitch"&gt;&lt;/iframe&gt;
&lt;/div&gt;
 

&lt;p&gt;To get our button we need to populate the fields for the GitHub user or organization name and the name of the repository for which you want to create a button. &lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fmdgna7u4l22qv96qr8nk.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fmdgna7u4l22qv96qr8nk.png" alt="Populating the GitHub details"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;We then click the Generate button and the app will create Markdown and HTML code for a button:&lt;/p&gt;

&lt;p&gt;&lt;code&gt;[![Remix on Glitch](https://cdn.glitch.com/2703baf2-b643-4da7-ab91-7ee2a2d00b5b%2Fremix-button.svg)](https://glitch.com/edit/#!/import/github/glitchdotcom/starter-discord)&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;We can now take this code and add it to our GitHub repo. In our case, we're going to edit the &lt;code&gt;readme.md&lt;/code&gt; file in the &lt;a href="https://github.com/glitchdotcom/starter-discord" rel="noopener noreferrer"&gt;&lt;code&gt;starter-discord&lt;/code&gt;&lt;/a&gt; project.&lt;/p&gt;

&lt;p&gt;To do this we go to the GitHub project and scroll down to the readme text below the list of files. We then click on the edit button (it looks like a pencil!) and add our Markdown button code.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fepo3ml3kb2jyn6i1jkjy.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fepo3ml3kb2jyn6i1jkjy.png" alt="Adding the Markdown button code"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;We scroll down to the bottom of the page, add a commit message, and commit our new code.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fh7298yngz4na5icv1s8o.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fh7298yngz4na5icv1s8o.png" alt="Committing our button code"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;And now we can see the button in our project's readme file.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Firowfo4tfpr699y1raeo.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Firowfo4tfpr699y1raeo.png" alt="Our new Remix button"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Now, if we click on the button, we'll get a brand-new Glitch app running the Discord starter kit which you can use to create your own Discord bot, or whatever project you add the button to!&lt;/p&gt;

&lt;p&gt;P.S. There's also other cool things you can do, like populating environment variables in your &lt;code&gt;.env&lt;/code&gt; file automatically, using this app. You can read about those in the app's documentation.&lt;/p&gt;

</description>
      <category>glitch</category>
      <category>git</category>
      <category>github</category>
      <category>discord</category>
    </item>
    <item>
      <title>Get Deployment Right on Day 1</title>
      <dc:creator>James Turnbull</dc:creator>
      <pubDate>Tue, 28 Jan 2020 19:26:44 +0000</pubDate>
      <link>https://dev.to/jamtur01/get-deployment-right-on-day-1-2lcp</link>
      <guid>https://dev.to/jamtur01/get-deployment-right-on-day-1-2lcp</guid>
      <description>&lt;p&gt;Deployment gets the code you and your team have written out into the world. Any system you've written that isn't deployed, and in front of a user, isn't generating value. It's also not giving you feedback about your product and how it helps your users. Hence getting deployment going is one of the first things most engineering teams (even if that's just you on day 1!) do when they start to build a product.&lt;/p&gt;

&lt;p&gt;Like most items constructed at the start of a company or product's life, we often create the fastest, simplest ~solution~ hack as our deployment system: "I just need something that works, and I'll worry about making it better later."&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;This is a mistake.&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The system that gets your code from your engineers to the customer is the most crucial piece of engineering tooling you'll build: &lt;strong&gt;ever&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;The capabilities, quality, and performance of your deployment system directly correlate to the speed to market of your product, both in generating value and addressing user feedback and issues. Not only this, your deployment frequency and outcomes represent one of the (rare) early measurements of engineering velocity and quality. If your product or business partners are complaining about things moving too slow, then this is one of the first places you should look. Finally, getting code in front of users and seeing your product in action makes your engineers happy.&lt;/p&gt;

&lt;p&gt;You may get a lot of pressure to develop features and not spend time on this kind of tooling, as a manager you need to make sure that you have given the team room to develop this tooling.&lt;/p&gt;

&lt;h2&gt;
  
  
  Building that deployment system
&lt;/h2&gt;

&lt;p&gt;When you build that crucial first deployment system you need to build upon the right principles: what can be summarized as CI/CD or Continuous Integration/Continuous Delivery:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Everybody should be able to deploy.&lt;/li&gt;
&lt;li&gt;Deployment should be automatic and continuous.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;You can then scale your deployment system instead of refactoring it every time your organization scales. This comes with some risk of premature optimization but I believe that risk is outweighed by the rewards: faster deployment, enhanced developer happiness, and faster speed to market.&lt;/p&gt;

&lt;p&gt;Let's look at each principle.&lt;/p&gt;

&lt;h3&gt;
  
  
  Everyone should be able to deploy
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Fiip4f8koezowbtubyf76.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Fiip4f8koezowbtubyf76.png" alt="Everyone deploys"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Everyone on your team should be able to deploy. A good deployment system should be continuous and not gated. Deployment systems triggered by intermediaries, "approvers," or small groups, like QA teams, are inherently hamstrung. Firstly, this model removes a developer's ownership of the deployment of their code and its outcomes. Worse, it sometimes transfers ownership of the code that is being deployed, disconnecting an engineer from the reality of the systems for which they write code. Secondly, these models are slow by design. They exist to put roadblocks in the way of your code getting deployed.&lt;/p&gt;

&lt;h3&gt;
  
  
  Deployment should be automatic and continuous
&lt;/h3&gt;

&lt;p&gt;Code sitting in repositories or in branches is also not adding value. Any deployment process should optimize for putting the system into use as fast as possible. My preference has always been to deploy any code merged to &lt;code&gt;master&lt;/code&gt; automatically to production.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Fl9e1h15pj0fbjiq5tizf.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Fl9e1h15pj0fbjiq5tizf.png" alt="deploy automatically from master"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;There has also always been &lt;a href="https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows" rel="noopener noreferrer"&gt;a&lt;/a&gt; &lt;a href="https://martinfowler.com/bliki/FeatureBranch.html" rel="noopener noreferrer"&gt;lot&lt;/a&gt; &lt;a href="https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf" rel="noopener noreferrer"&gt;of&lt;/a&gt; &lt;a href="https://nvie.com/posts/a-successful-git-branching-model/" rel="noopener noreferrer"&gt;debate&lt;/a&gt; over how to manage development and code branching processes to get that code merged. Again, my personal preference has always been to make use of &lt;a href="http://scottchacon.com/2011/08/31/github-flow.html" rel="noopener noreferrer"&gt;GitHub Flow&lt;/a&gt; which states:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;The &lt;code&gt;master&lt;/code&gt; branch can always be deployed.&lt;/li&gt;
&lt;li&gt;Everything is branched off &lt;code&gt;master&lt;/code&gt; and named for a feature or issue.&lt;/li&gt;
&lt;li&gt;Do your work on that branch locally and regularly push your work upstream to the server.&lt;/li&gt;
&lt;li&gt;Merge by opening a pull request, having it reviewed, and then merging it to &lt;code&gt;master&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;Automatically deploy &lt;code&gt;master&lt;/code&gt;.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Ft80ybja8ozhp2lfh4td8.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Ft80ybja8ozhp2lfh4td8.png" alt="GitHub flow branching"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;With the GitHub Flow, we optimize for small, short-lived branches to reduce the risk of merge conflicts and disruption and to increase the velocity of code being pushed and deployed. Your commit-to-deploy time is another good, early measure of your team's development velocity.&lt;/p&gt;

&lt;p&gt;If you are worried about inter-dependencies or features being developed over longer time frames, for example in stages, you can make use of &lt;a href="https://martinfowler.com/articles/feature-toggles.html" rel="noopener noreferrer"&gt;feature flags&lt;/a&gt; to hide features that aren't ready for prime time or not yet complete. Feature flags also encourage early user and integration testing. They additionally provide your engineers with a sense that a feature is evolving and work is progressing, rather than being stuck in a long-lived branch.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;If you do have to put in an approval process to satisfy compliance or regulatory requirements then the GitHub Flow allows you to lock off the &lt;code&gt;master&lt;/code&gt; branch from direct pushes and require approvals on pull requests.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;h2&gt;
  
  
  Deployment FTW
&lt;/h2&gt;

&lt;p&gt;Once you have a deployment system that provides everyone on your team the ability to deploy automatically and continuously, the return on investment will be tangible and measurable. If your deployment system meets these two objectives then you're building on a good foundation that will allow you to scale as your team and company grows.&lt;/p&gt;

</description>
      <category>devops</category>
      <category>deployment</category>
      <category>pipeline</category>
      <category>engineering</category>
    </item>
  </channel>
</rss>
