Feed powered byStream Blue Logo Copy 5Created with Sketch.
GitHub

GitHub

DevOps / Build, Test, Deploy / Code Collaboration & Version Control

Decision about GitHub, Gatsby, Netlify, styled-components, Redux.js, React, Firebase, Google, Frontend, ReactRally

Avatar of johnnyxbell
Sr. Software Engineer at StackShare ·
GitHubGitHub
GatsbyGatsby
NetlifyNetlify
styled-componentsstyled-components
Redux.jsRedux.js
ReactReact
FirebaseFirebase
#Google
#Frontend
#ReactRally

I was building a personal project that I needed to store items in a real time database. I am more comfortable with my Frontend skills than my backend so I didn't want to spend time building out anything in Ruby or Go.

I stumbled on Firebase by #Google, and it was really all I needed. It had realtime data, an area for storing file uploads and best of all for the amount of data I needed it was free!

I built out my application using tools I was familiar with, React for the framework, Redux.js to manage my state across components, and styled-components for the styling.

Now as this was a project I was just working on in my free time for fun I didn't really want to pay for hosting. I did some research and I found Netlify. I had actually seen them at #ReactRally the year before and deployed a Gatsby site to Netlify already.

Netlify was very easy to setup and link to my GitHub account you select a repo and pretty much with very little configuration you have a live site that will deploy every time you push to master.

With the selection of these tools I was able to build out my application, connect it to a realtime database, and deploy to a live environment all with $0 spent.

If you're looking to build out a small app I suggest giving these tools a go as you can get your idea out into the real world for absolutely no cost.

22 upvotes·4 comments·9.6K views

Decision at Stream about Go, Jenkins, GitHub, Travis CI, CodeCollaborationVersionControl, ContinuousIntegration

Avatar of tschellenbach
GoGo
JenkinsJenkins
GitHubGitHub
Travis CITravis CI
#CodeCollaborationVersionControl
#ContinuousIntegration

Releasing new versions of our services is done by Travis CI. Travis first runs our test suite. Once it passes, it publishes a new release binary to GitHub.

Common tasks such as installing dependencies for the Go project, or building a binary are automated using plain old Makefiles. (We know, crazy old school, right?) Our binaries are compressed using UPX.

Travis has come a long way over the past years. I used to prefer Jenkins in some cases since it was easier to debug broken builds. With the addition of the aptly named “debug build” button, Travis is now the clear winner. It’s easy to use and free for open source, with no need to maintain anything.

#ContinuousIntegration #CodeCollaborationVersionControl

22 upvotes·1 comment·977 views

Decision at SendGrid about Buildkite, GitHub, Languages, Databases, InMemoryDatabases, DataStores

Avatar of sethgrid
Principal Software Developer at SendGrid ·
BuildkiteBuildkite
GitHubGitHub
#Languages
#Databases
#InMemoryDatabases
#DataStores

When we've gone through code reviews (every code and config change goes through a code review) and feel good about the level of automated testing (no one can sign off on their own code's functionality; a quality assurance engineer or other developer has to verify functionality), we merge our changes via a bot that interacts with GitHub (the bot maintains our versions and change logs). After Buildkite has a green build and our binary is shipped to our repo servers, we are good to roll out deploys to our data centers and to keep pushing the needle on the performance of our system.

#Languages #DataStores #Databases #InMemoryDatabases

15 upvotes·674 views

Decision at Shopify about GitHub, Rails

Avatar of kirs
Production Engineer at Shopify ·
GitHubGitHub
RailsRails

The core Shopify app has remained a Rails monolith, but we also have hundreds of other Rails apps across the organization. These are not microservices, but domain-specific apps: Shipping (talks with various shipping providers), Identity (single sign on across all Shopify stores), and App Store to name a few. Managing a hundred apps and keeping them up to date with security updates can be tough, so we've developed ServicesDB, an internal app that keeps track of all production services and helps developers to make sure that they don't miss anything important.

ServicesDB keeps a checklist for each app: ownership, uptime, logs, on-call rotation, exception reporting, and gem security updates. If there are problems with any of those, ServicesDB opens a GitHub issue and pings owners of the app to ask them to address it. ServicesDB also makes it easy to query the infrastructure and answer questions like, “How many apps are on Rails 4.2? How many apps are using an outdated version of gem X? Which apps are calling this service?”.

15 upvotes·653 views

Decision at ACK Foundry about Bitbucket, GitLab Pages, GitLab CI, GitHub, GitLab, OpenSourceCloud

Avatar of thebadmonkeydev
Senior Software Engineer at StackShare ·
BitbucketBitbucket
GitLab PagesGitLab Pages
GitLab CIGitLab CI
GitHubGitHub
GitLabGitLab
#OpenSourceCloud

I use GitLab when building side-projects and MVPs. The interface and interactions are close enough to those of GitHub to prevent cognitive switching costs between professional and personal projects hosted on different services.

GitLab also provides a suite of tools including issue/project management, CI/CD with GitLab CI, and validation/landing pages with GitLab Pages. With everything in one place, on an #OpenSourceCloud GitLab makes it easy for me to manage much larger projects on my own, than would be possible with other solutions or tools.

It's petty I know, but I can also read the GitLab code diffs far more easily than diffs on GitHub or Bitbucket...they just look better in my opinion.

12 upvotes·10.3K views

Decision at Kong about Zapier, GitHub, New Relic, GitHubAnalytics, OpenSourceCommunityAnalytics, CommunityAnalytics, RepoAnalytics

Avatar of coopr
Director of Ecosystem at Kong Inc. ·
ZapierZapier
GitHubGitHub
New RelicNew Relic
#GitHubAnalytics
#OpenSourceCommunityAnalytics
#CommunityAnalytics
#RepoAnalytics

I've used more and more of New Relic Insights here in my work at Kong. New Relic Insights is a "time series event database as a service" with a super-easy API for inserting custom events, and a flexible query language for building visualization widgets and dashboards.

I'm a big fan of New Relic Insights when I have data I know I need to analyze, but perhaps I'm not exactly sure how I want to analyze it in the future. For example, at Kong we recently wanted to get some understanding of our open source community's activity on our GitHub repos. I was able to quickly configure GitHub to send webhooks to Zapier , which in turn posted the JSON to New Relic Insights.

Insights is schema-less and configuration-less - just start posting JSON key value pairs, then start querying your data.

Within minutes, data was flowing from GitHub to Insights, and I was building widgets on my Insights dashboard to help my colleagues visualize the activity of our open source community.

#GitHubAnalytics #OpenSourceCommunityAnalytics #CommunityAnalytics #RepoAnalytics

10 upvotes·20.1K views

Decision at StackShare about Slack, Docker, GitHub, CircleCI, StackDecisionsLaunch

Avatar of lukehamilton
Sr. Engineer at StackShare ·
SlackSlack
DockerDocker
GitHubGitHub
CircleCICircleCI
#StackDecisionsLaunch

We used CircleCI in conjunction with GitHub to achieve an integrated version control system continuous integration setup. CircleCI automatically runs our builds in a clean Docker container or virtual machine on every commit allowing us to stay on stop of any regressions as they arise. Additionally the notification system keeps our team up to date when issues do arise so we can get them fixed quickly. It even integrates with Slack to further reduce the friction in staying up to date with the status of our builds. With the automated deployment system once a build passes we can have it automatically deployed to our production environment so we can make sure our users always have the latest and greatest features.

#StackDecisionsLaunch

10 upvotes·5.4K views

Decision at Zulip about GitLab, GitHub

Avatar of tabbott
Founder at Zulip ·
GitLabGitLab
GitHubGitHub

I have mixed feelings on GitHub as a product and our use of it for the Zulip open source project. On the one hand, I do feel that being on GitHub helps people discover Zulip, because we have enough stars (etc.) that we rank highly among projects on the platform. and there is a definite benefit for lowering barriers to contribution (which is important to us) that GitHub has such a dominant position in terms of what everyone has accounts with.

But even ignoring how one might feel about their new corporate owner (MicroSoft), in a lot of ways GitHub is a bad product for open source projects. Years after the "Dear GitHub" letter, there are still basic gaps in its issue tracker: * You can't give someone permission to label/categorize issues without full write access to a project (including ability to merge things to master, post releases, etc.). * You can't let anyone with a GitHub account self-assign issues to themselves. * Many more similar issues.

It's embarrassing, because I've talked to GitHub product managers at various open source events about these things for 3 years, and they always agree the thing is important, but then nothing ever improves in the Issues product. Maybe the new management at MicroSoft will fix their product management situation, but if not, I imagine we'll eventually do the migration to GitLab.

We have a custom bot project, http://github.com/zulip/zulipbot, to deal with some of these issues where possible, and every other large project we talk to does the same thing, more or less.

8 upvotes·12K views

Decision at Netbeast about Mailjet, Intercom, Amplitude, Firebase, GitHub, Bitrise, Travis CI, Objective-C, Android SDK, React Native, End2end, SmartHome

Avatar of jsdario
Telecomm Engineering at Netbeast ·
MailjetMailjet
IntercomIntercom
AmplitudeAmplitude
FirebaseFirebase
GitHubGitHub
BitriseBitrise
Travis CITravis CI
Objective-CObjective-C
Android SDKAndroid SDK
React NativeReact Native
#End2end
#SmartHome

We are using React Native in #SmartHome to share the business logic between Android and iOS team and approach users with a unique brand experience. The drawback is that we require lots of native Android SDK and Objective-C modules, so a good part of the invested time is there. The gain for a app that relies less on native communication, sensors and OS tools should be even higher.

Also it helps us set different testing stages: we use Travis CI for the javascript (business logic), Bitrise to run build tests and @Detox for #end2end automated user tests.

We use a microservices structure on top of Zeit's @now that read from firebase. We use JWT auth to authenticate requests among services and from users, following GitHub philosophy of using the same infrastructure than its API consumers. Firebase is used mainly as a key-value store between services and as a backup database for users. We also use its authentication mechanisms.

You can be super locked-in if you also rely on it's analytics, but we use Amplitude for that, which offers us great insights. Intercom for communications with end-user and Mailjet for marketing.

8 upvotes·6.3K views

Decision at StackShare about Redis, CircleCI, Webpack, Amazon CloudFront, Amazon S3, GitHub, Heroku, Rails, Node.js, Apollo, Glamorous, React, Microservices, StackDecisionsLaunch, SSR, FrontEndRepoSplit

Avatar of ruswerner
Lead Engineer at StackShare ·
RedisRedis
CircleCICircleCI
WebpackWebpack
Amazon CloudFrontAmazon CloudFront
Amazon S3Amazon S3
GitHubGitHub
HerokuHeroku
RailsRails
Node.jsNode.js
ApolloApollo
GlamorousGlamorous
ReactReact
#Microservices
#StackDecisionsLaunch
#SSR
#FrontEndRepoSplit

StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

8 upvotes·4.7K views