Alternatives to Rundeck logo

Alternatives to Rundeck

Airplane, Jenkins, Ansible, Airflow, and StackStorm are the most popular alternatives and competitors to Rundeck.
202
343
+ 1
7

What is Rundeck and what are its top alternatives?

Rundeck is an open-source automation tool that helps to streamline routine operational tasks across complex services and environments. Key features of Rundeck include job scheduling, workflow automation, secure access control, and integration with various tools and platforms. Users can easily create customizable workflows, execute tasks remotely, and monitor job results through a centralized dashboard. However, some limitations of Rundeck include a steep learning curve for new users and challenges in scaling for large enterprises.

  1. Jenkins: Jenkins is an open-source automation server that helps automate various tasks in software development processes. Key features include continuous integration, continuous delivery, support for various plugins, and a vibrant community. Pros include a large ecosystem of plugins and integrations, while cons may include complexity for beginners and maintenance overhead.

  2. Ansible: Ansible is an open-source IT automation tool that allows users to automate configuration management, application deployment, and orchestration tasks. Key features include agentless architecture, simple automation language, and robust community support. Pros include easy configuration management and scalability, while cons may involve lack of graphical user interface for beginners.

  3. SaltStack: SaltStack is an open-source infrastructure automation platform that enables users to automate cloud management, server provisioning, and configuration tasks. Key features include remote execution, event-driven automation, and support for infrastructure as code. Pros include scalability and flexibility, while cons may include complexity in setup and configuration.

  4. Puppet: Puppet is an open-source configuration management tool that helps automate infrastructure provisioning, configuration, and management. Key features include declarative language, agent-based architecture, and support for role-based access control. Pros include robust reporting and scalability, while cons may involve a steep learning curve for beginners.

  5. Control-M: Control-M is an enterprise workload automation tool that helps orchestrate and automate IT processes across diverse applications and infrastructure. Key features include job scheduling, monitoring, and predictive analytics. Pros include support for various platforms and scalable architecture, while cons may include complexity in setup and licensing costs.

  6. Apache Airflow: Apache Airflow is an open-source workflow automation tool that helps users programmatically author, schedule, and monitor workflows. Key features include Directed Acyclic Graph (DAG) scheduling, extensibility through plugins, and rich user interface. Pros include flexibility and scalability, while cons may include a learning curve for complex workflows.

  7. Chef: Chef is an open-source configuration management tool that enables users to automate infrastructure provisioning, configuration, and compliance tasks. Key features include infrastructure as code, recipe-based configuration, and support for multiple platforms. Pros include repeatability and auditability, while cons may involve complexity in setup and maintenance.

  8. Nomad: Nomad is an open-source cluster and application scheduler designed for microservices and batch workloads. Key features include automated deployment, scaling, and upgrading of applications across multiple infrastructure environments. Pros include simplicity and flexibility, while cons may include limited out-of-the-box integrations.

  9. Octopus Deploy: Octopus Deploy is a deployment automation tool that helps users automate application deployments across development, test, and production environments. Key features include release management, deployment orchestration, and support for various deployment strategies. Pros include ease of use and integration with popular DevOps tools, while cons may involve licensing costs for larger teams.

  10. RunDeck Pro: RunDeck Pro is a commercial version of the open-source RunDeck tool that offers additional features and support for enterprise users. Key features include enterprise-class security, scalability, and support services. Pros include enhanced functionality and enterprise-grade support, while cons may involve licensing costs for advanced features.

Top Alternatives to Rundeck

  • Airplane
    Airplane

    It is a developer-centric approach to building internal UIs and workflows. Turn APIs, SQL queries, and scripts into apps for the entire team. ...

  • Jenkins
    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. ...

  • Ansible
    Ansible

    Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. Ansible’s goals are foremost those of simplicity and maximum ease of use. ...

  • Airflow
    Airflow

    Use Airflow to author workflows as directed acyclic graphs (DAGs) of tasks. The Airflow scheduler executes your tasks on an array of workers while following the specified dependencies. Rich command lines utilities makes performing complex surgeries on DAGs a snap. The rich user interface makes it easy to visualize pipelines running in production, monitor progress and troubleshoot issues when needed. ...

  • StackStorm
    StackStorm

    StackStorm is a platform for integration and automation across services and tools. It ties together your existing infrastructure and application environment so you can more easily automate that environment -- with a particular focus on taking actions in response to events. ...

  • Puppet Labs
    Puppet Labs

    Puppet is an automated administrative engine for your Linux, Unix, and Windows systems and performs administrative tasks (such as adding users, installing packages, and updating server configurations) based on a centralized specification. ...

  • AWX
    AWX

    AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is the upstream project for Tower, a commercial derivative of AWX. Ansible Towers powers enterprise automation by adding control, security and delegation capabilities to Ansible environments. ...

  • Tower
    Tower

    Use all of Git's powerful feature set - in a GUI that makes you more productive. ...

Rundeck alternatives & related posts

Airplane logo

Airplane

7
12
0
Developer-centric approach to building internal UIs and workflows
7
12
+ 1
0
PROS OF AIRPLANE
    Be the first to leave a pro
    CONS OF AIRPLANE
      Be the first to leave a con

      related Airplane posts

      Jenkins logo

      Jenkins

      58.2K
      49.7K
      2.2K
      An extendable open source continuous integration server
      58.2K
      49.7K
      + 1
      2.2K
      PROS OF JENKINS
      • 523
        Hosted internally
      • 469
        Free open source
      • 318
        Great to build, deploy or launch anything async
      • 243
        Tons of integrations
      • 211
        Rich set of plugins with good documentation
      • 111
        Has support for build pipelines
      • 68
        Easy setup
      • 66
        It is open-source
      • 53
        Workflow plugin
      • 13
        Configuration as code
      • 12
        Very powerful tool
      • 11
        Many Plugins
      • 10
        Continuous Integration
      • 10
        Great flexibility
      • 9
        Git and Maven integration is better
      • 8
        100% free and open source
      • 7
        Github integration
      • 7
        Slack Integration (plugin)
      • 6
        Easy customisation
      • 6
        Self-hosted GitLab Integration (plugin)
      • 5
        Docker support
      • 5
        Pipeline API
      • 4
        Fast builds
      • 4
        Platform idnependency
      • 4
        Hosted Externally
      • 4
        Excellent docker integration
      • 3
        It`w worked
      • 3
        Customizable
      • 3
        Can be run as a Docker container
      • 3
        It's Everywhere
      • 3
        JOBDSL
      • 3
        AWS Integration
      • 2
        Easily extendable with seamless integration
      • 2
        PHP Support
      • 2
        Build PR Branch Only
      • 2
        NodeJS Support
      • 2
        Ruby/Rails Support
      • 2
        Universal controller
      • 2
        Loose Coupling
      CONS OF JENKINS
      • 13
        Workarounds needed for basic requirements
      • 10
        Groovy with cumbersome syntax
      • 8
        Plugins compatibility issues
      • 7
        Lack of support
      • 7
        Limited abilities with declarative pipelines
      • 5
        No YAML syntax
      • 4
        Too tied to plugins versions

      related Jenkins posts

      Tymoteusz Paul
      Devops guy at X20X Development LTD · | 23 upvotes · 9.6M views

      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.

      See more
      Thierry Schellenbach

      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

      See more
      Ansible logo

      Ansible

      19K
      15.4K
      1.3K
      Radically simple configuration-management, application deployment, task-execution, and multi-node orchestration engine
      19K
      15.4K
      + 1
      1.3K
      PROS OF ANSIBLE
      • 284
        Agentless
      • 210
        Great configuration
      • 199
        Simple
      • 176
        Powerful
      • 155
        Easy to learn
      • 69
        Flexible
      • 55
        Doesn't get in the way of getting s--- done
      • 35
        Makes sense
      • 30
        Super efficient and flexible
      • 27
        Powerful
      • 11
        Dynamic Inventory
      • 9
        Backed by Red Hat
      • 7
        Works with AWS
      • 6
        Cloud Oriented
      • 6
        Easy to maintain
      • 4
        Vagrant provisioner
      • 4
        Simple and powerful
      • 4
        Multi language
      • 4
        Simple
      • 4
        Because SSH
      • 4
        Procedural or declarative, or both
      • 4
        Easy
      • 3
        Consistency
      • 2
        Well-documented
      • 2
        Masterless
      • 2
        Debugging is simple
      • 2
        Merge hash to get final configuration similar to hiera
      • 2
        Fast as hell
      • 1
        Manage any OS
      • 1
        Work on windows, but difficult to manage
      • 1
        Certified Content
      CONS OF ANSIBLE
      • 8
        Dangerous
      • 5
        Hard to install
      • 3
        Doesn't Run on Windows
      • 3
        Bloated
      • 3
        Backward compatibility
      • 2
        No immutable infrastructure

      related Ansible posts

      Tymoteusz Paul
      Devops guy at X20X Development LTD · | 23 upvotes · 9.6M views

      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.

      See more
      Sebastian Gębski

      Heroku was a decent choice to start a business, but at some point our platform was too big, too complex & too heterogenic, so Heroku started to be a constraint, not a benefit. First, we've started containerizing our apps with Docker to eliminate "works in my machine" syndrome & uniformize the environment setup. The first orchestration was composed with Docker Compose , but at some point it made sense to move it to Kubernetes. Fortunately, we've made a very good technical decision when starting our work with containers - all the container configuration & provisions HAD (since the beginning) to be done in code (Infrastructure as Code) - we've used Terraform & Ansible for that (correspondingly). This general trend of containerisation was accompanied by another, parallel & equally big project: migrating environments from Heroku to AWS: using Amazon EC2 , Amazon EKS, Amazon S3 & Amazon RDS.

      See more
      Airflow logo

      Airflow

      1.7K
      2.7K
      128
      A platform to programmaticaly author, schedule and monitor data pipelines, by Airbnb
      1.7K
      2.7K
      + 1
      128
      PROS OF AIRFLOW
      • 53
        Features
      • 14
        Task Dependency Management
      • 12
        Beautiful UI
      • 12
        Cluster of workers
      • 10
        Extensibility
      • 6
        Open source
      • 5
        Complex workflows
      • 5
        Python
      • 3
        Good api
      • 3
        Apache project
      • 3
        Custom operators
      • 2
        Dashboard
      CONS OF AIRFLOW
      • 2
        Observability is not great when the DAGs exceed 250
      • 2
        Running it on kubernetes cluster relatively complex
      • 2
        Open source - provides minimum or no support
      • 1
        Logical separation of DAGs is not straight forward

      related Airflow posts

      Data science and engineering teams at Lyft maintain several big data pipelines that serve as the foundation for various types of analysis throughout the business.

      Apache Airflow sits at the center of this big data infrastructure, allowing users to “programmatically author, schedule, and monitor data pipelines.” Airflow is an open source tool, and “Lyft is the very first Airflow adopter in production since the project was open sourced around three years ago.”

      There are several key components of the architecture. A web UI allows users to view the status of their queries, along with an audit trail of any modifications the query. A metadata database stores things like job status and task instance status. A multi-process scheduler handles job requests, and triggers the executor to execute those tasks.

      Airflow supports several executors, though Lyft uses CeleryExecutor to scale task execution in production. Airflow is deployed to three Amazon Auto Scaling Groups, with each associated with a celery queue.

      Audit logs supplied to the web UI are powered by the existing Airflow audit logs as well as Flask signal.

      Datadog, Statsd, Grafana, and PagerDuty are all used to monitor the Airflow system.

      See more

      We are a young start-up with 2 developers and a team in India looking to choose our next ETL tool. We have a few processes in Azure Data Factory but are looking to switch to a better platform. We were debating Trifacta and Airflow. Or even staying with Azure Data Factory. The use case will be to feed data to front-end APIs.

      See more
      StackStorm logo

      StackStorm

      79
      185
      31
      Open Source IFTTT for Ops: event-driven automation, security responses, auto-remediation with workflow engine & ChatOps
      79
      185
      + 1
      31
      PROS OF STACKSTORM
      • 7
        Auto-remediation
      • 5
        Integrations
      • 4
        Automation
      • 4
        Complex workflows
      • 3
        Open source
      • 2
        Beautiful UI
      • 2
        ChatOps
      • 2
        Python
      • 1
        Extensibility
      • 1
        Slack
      CONS OF STACKSTORM
      • 3
        Complexity
      • 1
        There are not enough sources of information

      related StackStorm posts

      Puppet Labs logo

      Puppet Labs

      1.1K
      792
      227
      Server automation framework and application
      1.1K
      792
      + 1
      227
      PROS OF PUPPET LABS
      • 52
        Devops
      • 44
        Automate it
      • 26
        Reusable components
      • 21
        Dynamic and idempotent server configuration
      • 18
        Great community
      • 12
        Very scalable
      • 12
        Cloud management
      • 10
        Easy to maintain
      • 9
        Free tier
      • 6
        Works with Amazon EC2
      • 4
        Declarative
      • 4
        Ruby
      • 3
        Works with Azure
      • 3
        Works with OpenStack
      • 2
        Nginx
      • 1
        Ease of use
      CONS OF PUPPET LABS
      • 3
        Steep learning curve
      • 1
        Customs types idempotence

      related Puppet Labs posts

      Shared insights
      on
      SaltSaltPuppet LabsPuppet LabsAnsibleAnsible
      at

      By 2014, the DevOps team at Lyft decided to port their infrastructure code from Puppet to Salt. At that point, the Puppet code based included around "10,000 lines of spaghetti-code,” which was unfamiliar and challenging to the relatively new members of the DevOps team.

      “The DevOps team felt that the Puppet infrastructure was too difficult to pick up quickly and would be impossible to introduce to [their] developers as the tool they’d use to manage their own services.”

      To determine a path forward, the team assessed both Ansible and Salt, exploring four key areas: simplicity/ease of use, maturity, performance, and community.

      They found that “Salt’s execution and state module support is more mature than Ansible’s, overall,” and that “Salt was faster than Ansible for state/playbook runs.” And while both have high levels of community support, Salt exceeded expectations in terms of friendless and responsiveness to opened issues.

      See more
      Marcel Kornegoor

      Since #ATComputing is a vendor independent Linux and open source specialist, we do not have a favorite Linux distribution. We mainly use Ubuntu , Centos Debian , Red Hat Enterprise Linux and Fedora during our daily work. These are also the distributions we see most often used in our customers environments.

      For our #ci/cd training, we use an open source pipeline that is build around Visual Studio Code , Jenkins , VirtualBox , GitHub , Docker Kubernetes and Google Compute Engine.

      For #ServerConfigurationAndAutomation, we have embraced and contributed to Ansible mainly because it is not only flexible and powerful, but also straightforward and easier to learn than some other (open source) solutions. On the other hand: we are not affraid of Puppet Labs and Chef either.

      Currently, our most popular #programming #Language course is Python . The reason Python is so popular has to do with it's versatility, but also with its low complexity. This helps sysadmins to write scripts or simple programs to make their job less repetitive and automating things more fun. Python is also widely used to communicate with (REST) API's and for data analysis.

      See more
      AWX logo

      AWX

      140
      259
      1
      Centralize and control your IT infrastructure with a visual dashboard
      140
      259
      + 1
      1
      PROS OF AWX
      • 1
        Open source
      CONS OF AWX
        Be the first to leave a con

        related AWX posts

        Shared insights
        on
        KubernetesKubernetesHarborHarborAWXAWXDockerDocker

        We are operating a smart water purification plant called AAA. AAA has a Docker-based AI platform, and we want to build several water purification plants like this. In addition, it plans to create a headquarters that manages these water purification plants in an integrated way and build a big data platform there. Although I don't know if Ansible AWX can replace Harbor or Kubernetes among the three solutions above, I would like to know which solution is suitable for us and why. May your business go well...

        See more
        Tower logo

        Tower

        213
        360
        80
        The most powerful Git client for Mac & Windows
        213
        360
        + 1
        80
        PROS OF TOWER
        • 19
          Git
        • 16
          Just works
        • 10
          Version control
        • 6
          Awesome
        • 6
          Simple layout
        • 4
          Multiple windows
        • 3
          Automatic repo discovery
        • 3
          Multiple tabs
        • 2
          Submodule support
        • 2
          Github integration
        • 2
          Full featured client
        • 2
          Uses standard git terminology and methods
        • 2
          Gitflow support
        • 2
          Interactive stage or discard by hunks or lines
        • 1
          SAS
        CONS OF TOWER
        • 5
          Expensive
        • 4
          Subscription based
        • 1
          No side by side diff
        • 0
          Merge conflict resolution impossible/unclear

        related Tower posts

        Cees Timmerman

        Tower appears to be between GitKraken and SourceTree in detail, but gave two scary error dialogs when attempting to merge resulted in a conflict. Doing the same in SourceTree just worked and showed the conflict in its handy file view that's always visible (unlike Tower's mere "Merge branch 'X' into develop" message when the commit is selected).

        Both GitKraken and Tower lack the commit hash in their history overview, requiring one to select a commit to see it.

        GitKraken appears to be the only Windows 10 Git GUI suitable for night shifts, but like Tower is only free for 30 days, unlike SourceTree.

        See more