What is Harness.io and what are its top alternatives?
Harness.io is a continuous delivery platform that automates the entire software release process, allowing teams to deliver applications more quickly and efficiently. It provides features such as automated deployments, intelligent verification, and built-in security. However, some limitations of Harness.io include its pricing structure, which can be expensive for small teams, and the complexity of setting up and configuring the platform.
- Jenkins: Jenkins is an open-source automation server that helps automate various tasks in the software development process. Key features include continuous integration, automated testing, and support for a wide range of plugins. Pros include its flexibility and large community support, but it may require more manual configuration compared to Harness.io.
- CircleCI: CircleCI is a cloud-based continuous integration and delivery platform. It offers features such as automated testing, parallelism, and integration with popular version control systems. Pros include its scalability and ease of use, but some users may find it less flexible than Harness.io.
- GitLab CI/CD: GitLab CI/CD is a part of the GitLab DevOps platform that provides continuous integration and continuous deployment capabilities. It offers features such as Docker container support, code quality analysis, and Kubernetes integration. Pros include its all-in-one platform and strong version control capabilities, but it may require more setup compared to Harness.io.
- Travis CI: Travis CI is a cloud-based continuous integration platform that is easy to set up with GitHub repositories. Key features include customizable build environments, parallel testing, and fast feedback loops. Pros include its simplicity and integration with GitHub, but it may not be as feature-rich as Harness.io.
- TeamCity: TeamCity is a continuous integration and deployment server from JetBrains. It offers features such as build pipelines, code quality analysis, and integration with popular version control systems. Pros include its extensive integration options and compatibility with multiple programming languages, but it may require more maintenance than Harness.io.
- Bamboo: Bamboo is a continuous integration and deployment tool from Atlassian. It provides features such as customizable build pipelines, parallel builds, and tight integration with Jira and Bitbucket. Pros include its seamless integration with other Atlassian products and user-friendly interface, but it may not have as many advanced features as Harness.io.
- GoCD: GoCD is an open-source continuous delivery tool from ThoughtWorks. It offers features such as advanced workflow modeling, value stream mapping, and support for complex deployment scenarios. Pros include its flexibility and extensibility through plugins, but it may have a steeper learning curve compared to Harness.io.
- Spinnaker: Spinnaker is an open-source continuous delivery platform developed by Netflix and Google. It provides features such as automated deployment pipelines, support for multiple cloud providers, and canary releases. Pros include its scalability and multi-cloud support, but it may require more setup and configuration compared to Harness.io.
- Octopus Deploy: Octopus Deploy is a deployment automation tool for .NET developers. It offers features such as release management, infrastructure as code, and integration with popular CI/CD platforms. Pros include its support for Microsoft technologies and easy-to-use interface, but it may not be as versatile as Harness.io for non-.NET projects.
- Codeship: Codeship is a cloud-based continuous integration and delivery platform. It provides features such as parallel testing, Docker support, and customizable pipelines. Pros include its ease of use and fast setup, but some users may find it lacking in advanced deployment features compared to Harness.io.
Top Alternatives to Harness.io
- Jenkins
In a nutshell Jenkins CI is the leading open-source continuous integration server. Built with Java, it provides over 300 plugins to support building and testing virtually any project. ...
- CircleCI
Continuous integration and delivery platform helps software teams rapidly release code with confidence by automating the build, test, and deploy process. Offers a modern software development platform that lets teams ramp. ...
- GitLab
GitLab offers git repository management, code reviews, issue tracking, activity feeds and wikis. Enterprises install GitLab on-premise and connect it with LDAP and Active Directory servers for secure authentication and authorization. A single GitLab server can handle more than 25,000 users but it is also possible to create a high availability setup with multiple active servers. ...
- Spinnaker
Created at Netflix, it has been battle-tested in production by hundreds of teams over millions of deployments. It combines a powerful and flexible pipeline management system with integrations to the major cloud providers. ...
- AWS CodePipeline
CodePipeline builds, tests, and deploys your code every time there is a code change, based on the release process models you define. ...
- Google Cloud Build
Cloud Build lets you build software quickly across all languages. Get complete control over defining custom workflows for building, testing, and deploying across multiple environments such as VMs, serverless, Kubernetes, or Firebase. ...
- Buddy
Git platform for web and software developers with Docker-based tools for Continuous Integration and Deployment. ...
- DeployBot
DeployBot makes it simple to deploy your work anywhere. You can compile or process your code in a Docker container on our infrastructure, and we'll copy it to your servers once everything has been successfully built. ...
Harness.io alternatives & related posts
- Hosted internally523
- Free open source469
- Great to build, deploy or launch anything async318
- Tons of integrations243
- Rich set of plugins with good documentation211
- Has support for build pipelines111
- Easy setup68
- It is open-source66
- Workflow plugin53
- Configuration as code13
- Very powerful tool12
- Many Plugins11
- Continuous Integration10
- Great flexibility10
- Git and Maven integration is better9
- 100% free and open source8
- Slack Integration (plugin)7
- Github integration7
- Self-hosted GitLab Integration (plugin)6
- Easy customisation6
- Pipeline API5
- Docker support5
- Fast builds4
- Hosted Externally4
- Excellent docker integration4
- Platform idnependency4
- AWS Integration3
- JOBDSL3
- It's Everywhere3
- Customizable3
- Can be run as a Docker container3
- It`w worked3
- Loose Coupling2
- NodeJS Support2
- Build PR Branch Only2
- Easily extendable with seamless integration2
- PHP Support2
- Ruby/Rails Support2
- Universal controller2
- Workarounds needed for basic requirements13
- Groovy with cumbersome syntax10
- Plugins compatibility issues8
- Lack of support7
- Limited abilities with declarative pipelines7
- No YAML syntax5
- Too tied to plugins versions4
related Jenkins posts
Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).
It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up
or vagrant reload
we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.
I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up
, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.
We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.
If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.
The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).
Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.
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
- Github integration226
- Easy setup177
- Fast builds153
- Competitively priced94
- Slack integration74
- Docker support55
- Awesome UI45
- Great customer support33
- Ios support18
- Hipchat integration14
- SSH debug access13
- Free for Open Source11
- Mobile support6
- Nodejs support5
- Bitbucket integration5
- YAML configuration5
- AWS CodeDeploy integration4
- Free for Github private repo3
- Great support3
- Clojurescript2
- Continuous Deployment2
- Parallelism2
- Clojure2
- OSX support2
- Simple, clean UI2
- Unstable1
- Ci1
- Favorite1
- Helpful documentation1
- Autoscaling1
- Extremely configurable1
- Works1
- Android support1
- Fair pricing1
- All inclusive testing1
- Japanese in rspec comment appears OK1
- Build PR Branch Only1
- So circular1
- Easy setup, easy to understand, fast and reliable1
- Parallel builds for slow test suites1
- Easy setup. 2.0 is fast!1
- Easy to deploy to private servers1
- Really easy to use1
- Stable0
- Unstable12
- Scammy pricing structure6
- Aggressive Github permissions0
related CircleCI posts
Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).
It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up
or vagrant reload
we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.
I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up
, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.
We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.
If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.
The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).
Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.
We actually started out on Travis CI, but we've migrated our main builds to CircleCI, and it's been a huge improvement.
The reason it's been a huge improvement is that Travis CI has a fundamentally bad design for their images, where they start with a standard base Linux image containing tons of packages (several versions of postgres, every programming language environment, etc). This is potentially nice for the "get builds for a small project running quickly" use case, but it's a total disaster for a larger project that needs a decent number of dependencies and cares about the performance and reliability of their build.
This issue is exacerbated by their networking infrastructure being unreliable; we usually saw over 1% of builds failing due to transient networking errors in Travis CI, even after we added retries to the most frequently failing operations like apt update
or pip install
. And they never install Ubuntu's point release updates to their images. So doing an apt update
, apt install
, or especially apt upgrade
would take forever. We ended up writing code to actually uninstall many of their base packages and pin the versions of hundreds of others to get a semi-fast, semi-reliable build. It was infuriating.
The CircleCI v2.0 system has the right design for a CI system: we can customize the base image to start with any expensive-to-install packages we need for our build, and we can update that image if and when we want to. The end result is that when migrating, we were able to delete all the hacky optimizations mentioned above, while still ending up with a 50% faster build latency. And we've also had 5-10x fewer issues with networking-related flakes, which means one doesn't have to constantly check whether a build failure is actually due to an issue with the code under test or "just another networking flake".
- Self hosted508
- Free430
- Has community edition339
- Easy setup242
- Familiar interface240
- Includes many features, including ci137
- Nice UI113
- Good integration with gitlabci84
- Simple setup57
- Free private repository34
- Has an official mobile app34
- Continuous Integration31
- Open source, great ui (like github)22
- Slack Integration18
- Full CI flow14
- Free and unlimited private git repos11
- User, group, and project access management is simple10
- All in one (Git, CI, Agile..)9
- Built-in CI8
- Intuitive UI8
- Both public and private Repositories6
- Full DevOps suite with Git6
- Build/pipeline definition alongside code5
- CI5
- So easy to use5
- Integrated Docker Registry5
- It's powerful source code management tool5
- Issue system4
- Dockerized4
- Unlimited free repos & collaborators4
- Security and Stable4
- On-premises4
- It's fully integrated4
- Mattermost Chat client4
- Excellent4
- Great for team collaboration3
- Built-in Docker Registry3
- Low maintenance cost due omnibus-deployment3
- I like the its runners and executors feature3
- Free private repos3
- Because is the best remote host for git repositories3
- Not Microsoft Owned3
- Opensource3
- Groups of groups2
- Powerful software planning and maintaining tools2
- Review Apps feature2
- Kubernetes integration with GitLab CI2
- It includes everything I need, all packaged with docker2
- Multilingual interface2
- HipChat intergration2
- Powerful Continuous Integration System2
- One-click install through DigitalOcean2
- The dashboard with deployed environments2
- Native CI2
- Many private repo2
- Kubernetes Integration2
- Published IP list for whitelisting (gl-infra#434)2
- Wounderful2
- Beautiful2
- Supports Radius/Ldap & Browser Code Edits1
- Slow ui performance28
- Introduce breaking bugs every release8
- Insecure (no published IP list for whitelisting)6
- Built-in Docker Registry2
- Review Apps feature1
related GitLab posts
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.
We use GitLab CI because of the great native integration as a part of the GitLab framework and the linting-capabilities it offers. The visualization of complex pipelines and the embedding within the project overview made Gitlab CI even more convenient. We use it for all projects, all deployments and as a part of GitLab Pages.
While we initially used the Shell-executor, we quickly switched to the Docker-executor and use it exclusively now.
We formerly used Jenkins but preferred to handle everything within GitLab . Aside from the unification of our infrastructure another motivation was the "configuration-in-file"-approach, that Gitlab CI offered, while Jenkins support of this concept was very limited and users had to resort to using the webinterface. Since the file is included within the repository, it is also version controlled, which was a huge plus for us.
Spinnaker
- Mature13
- No GitOps3
- Configuration time1
- Management overhead1
- Ease of use1
related Spinnaker posts
LaunchDarkly is almost a five year old company, and our methodology for deploying was state of the art... for 2014. We recently undertook a project to modernize the way we #deploy our software, moving from Ansible-based deploy scripts that executed on our local machines, to using Spinnaker (along with Terraform and Packer) as the basis of our deployment system. We've been using Armory's enterprise Spinnaker offering to make this project a reality.
AWS CodePipeline
- Simple to set up13
- Managed service8
- GitHub integration4
- Parallel Execution3
- Automatic deployment2
- Manual Steps Available0
- No project boards2
- No integration with "Power" 365 tools1
related AWS CodePipeline posts
I'm the CTO of a marketing automation SaaS. Because of the continuously increasing load we moved to the AWSCloud. We are using more and more features of AWS: Amazon CloudWatch, Amazon SNS, Amazon CloudFront, Amazon Route 53 and so on.
Our main Database is MySQL but for the hundreds of GB document data we use MongoDB more and more. We started to use Redis for cache and other time sensitive operations.
On the front-end we use jQuery UI + Smarty but now we refactor our app to use Vue.js with Vuetify. Because our app is relatively complex we need to use vuex as well.
On the development side we use GitHub as our main repo, Docker for local and server environment and Jenkins and AWS CodePipeline for Continuous Integration.
We recently added new APIs to Jira to associate information about Builds and Deployments to Jira issues.
The new APIs were developed using a spec-first API approach for speed and sanity. The details of this approach are described in this blog post, and we relied on using Swagger and associated tools like Swagger UI.
A new service was created for managing the data. It provides a REST API for external use, and an internal API based on GraphQL. The service is built using Kotlin for increased developer productivity and happiness, and the Spring-Boot framework. PostgreSQL was chosen for the persistence layer, as we have non-trivial requirements that cannot be easily implemented on top of a key-value store.
The front-end has been built using React and querying the back-end service using an internal GraphQL API. We have plans of providing a public GraphQL API in the future.
New Jira Integrations: Bitbucket CircleCI AWS CodePipeline Octopus Deploy jFrog Azure Pipelines
- GCP easy integration2
- Container based2
- Vendor lock-in2
related Google Cloud Build posts
We recently moved our main applications from Heroku to Kubernetes . The 3 main driving factors behind the switch were scalability (database size limits), security (the inability to set up PostgreSQL instances in private networks), and costs (GCP is cheaper for raw computing resources).
We prefer using managed services, so we are using Google Kubernetes Engine with Google Cloud SQL for PostgreSQL for our PostgreSQL databases and Google Cloud Memorystore for Redis . For our CI/CD pipeline, we are using CircleCI and Google Cloud Build to deploy applications managed with Helm . The new infrastructure is managed with Terraform .
Read the blog post to go more in depth.
I use Google Cloud Build because it's my first foray into the CICD world(loving it so far), and I wanted to work with something GCP native to avoid giving permissions to other SaaS tools like CircleCI and Travis CI.
I really like it because it's free for the first 120 minutes, and it's one of the few CICD tools that enterprises are open to using since it's contained within GCP.
One of the unique things is that it has the Kaniko cache, which speeds up builds by creating intermediate layers within the docker image vs. pushing the full thing from the start. Helpful when you're installing just a few additional dependencies.
Feel free to checkout an example: Cloudbuild Example
- Easy setup56
- Docker53
- Continuous Integration50
- Integrations49
- Beautiful dashboard46
- Git hosting45
- Free43
- Unlimited pipelines42
- Monitoring39
- Backup39
- Great UX37
- On-Premises32
- Awesome support31
- AWS Integrations6
- Great UI5
- Hosted internally (Enterprise)3
- Slack integration3
- Continuous deployment3
- Simple deployments3
- Bitbucket integration3
- Github integration2
- UI and YML configuration2
- Node.js support2
- Azure integration2
- Amazing + free2
- Support for build pipelines1
- Docker support1
- Gitlab integration1
- Android support1
- Pushover integration1
- DigitalOcean integration1
- UpCloud integration1
- Shopify integration1
- New Relic integration0
- Rollbar integration0
- Sentry integration0
- Loggly integration0
- Datadog integration0
- Bugsnag integration0
- Honeybadger integration0
- Telegram integration0
- HipChat integration0
- Discord integration0
- Pushbulet integration0
- AWS integration0
- Slack Integration0
- Google Cloud integration0
- Heroku integration0
- Rackspace integration0
- Kubernetes support0
- Deleted account after 1 month of not pushing code1
related Buddy posts
I use Laravel because it's the most advances PHP framework out there, easy to maintain, easy to upgrade and most of all : easy to get a handle on, and to follow every new technology ! PhpStorm is our main software to code, as of simplicity and full range of tools for a modern application.
Google Analytics Analytics of course for a tailored analytics, Bulma as an innovative CSS framework, coupled with our Sass (Scss) pre-processor.
As of more basic stuff, we use HTML5, JavaScript (but with Vue.js too) and Webpack to handle the generation of all this.
To deploy, we set up Buddy to easily send the updates on our nginx / Ubuntu server, where it will connect to our GitHub Git private repository, pull and do all the operations needed with Deployer .
CloudFlare ensure the rapidity of distribution of our content, and Let's Encrypt the https certificate that is more than necessary when we'll want to sell some products with our Stripe api calls.
Asana is here to let us list all the functionalities, possibilities and ideas we want to implement.
DeployBot
- Easy setup26
- Seamless integrations20
- Free17
- Rocks10
- Docker1
- Not reliable1