The Red Hat Ansible Automation Platform (acquired by Red Hat in 2015) is a foundation for building and operating automation across an organization. The platform includes tools needed to implement enterprise-wide automation, and can automate resource provisioning, and IT environments and configuration of systems and devices. It can be used in a CI/CD process to provision the target environment and to then deploy the application on it.
$5,000
per year
TeamCity
Score 7.5 out of 10
N/A
TeamCity is a continuous integration server from Czeck company JetBrains.
It has helped save us so much time, as it was designed to automate mundane and repetitive tasks that we were using other tools to perform and that required so much manual intervention. It does not work very well within Windows environments, understandably, but I would love to see more integration. I want it to be sexy and attractive to more than just geeky sysadmins.
TeamCity is very quick and straightforward to get up and running. A new server and a handful of agents could be brought online in easily under an hour. The professional tier is completely free, full-featured, and offers a huge amount of growth potential. TeamCity does exceptionally well in a small-scale business or enterprise setting.
Debugging is easy, as it tells you exactly within your job where the job failed, even when jumping around several playbooks.
Ansible seems to integrate with everything, and the community is big enough that if you are unsure how to approach converting a process into a playbook, you can usually find something similar to what you are trying to do.
Security in AAP seems to be pretty straightforward. Easy to organize and identify who has what permissions or can only see the content based on the organization they belong to.
YAML is hard for many to adopt. Moving to a system that is not as white space sensitive would likely increase uptake.
AAP and EDA should be more closely aligned. There are differences that can trip users of the integration up. An example would be the way that variables are used.
Event-driven Ansible output is not as informative as AAP.
The customization is still fairly complex and is best managed by a dev support team. There is great flexibility, but with flexibility comes responsibility. It isn't always obvious to a developer how to make simple customizations.
Sometimes the process for dealing with errors in the process isn't obvious. Some paths to rerunning steps redo dependencies unnecessarily while other paths that don't are less obvious.
Even is if it's a great tool, we are looking to renew our licence for our production servers only. The product is very expensive to use, so we might look for a cheaper solution for our non-production servers. One of the solution we are looking, is AWX, free, and similar to AAP. This is be perfect for our non-production servers.
Great in almost every way compared to any other configuration management software. The only thing I wish for is python3 support. Other than that, YAML is much improved compared to the Ruby of Chef. The agentless nature is incredibly convenient for managing systems quickly, and if a member of your term has no terminal experience whatsoever they can still use the UI.
TeamCity runs really well, even when sharing a small instance with other applications. The user interface adequately conveys important information without being overly bloated, and it is snappy. There isn't any significant overhead to build agents or unit test runners that we have measured.
There is a lot of good documentation that Ansible and Red Hat provide which should help get someone started with making Ansible useful. But once you get to more complicated scenarios, you will benefit from learning from others. I have not used Red Hat support for work with Ansible, but many of the online resources are helpful.
I haven't thought of any right now other than just doing our own home-brewed shell scripts. Command line scripts. And how does this compare? It's light years ahead, especially with the ability to share credentials without giving the person the actual credentials. You can delegate that within, I guess what used to be called Ansible Tower, which is now the Ansible Automation platform. It lets you share, I can give you the keys without you being able to see the keys. It's great
TeamCity is a great on-premise Continuous Integration tool. Visual Studio Team Services (VSTS) is a hosted SAAS application in Microsoft's Cloud. VSTS is a Source Code Repository, Build and Release System, and Agile Project Management Platform - whereas TeamCity is a Build and Release System only. TeamCity's interface is easier to use than VSTS, and neither have a great deployment pipeline solution. But VSTS's natural integration with Microsoft products, Microsoft's Cloud, Integration with Azure Active Directory, and free, private, Source Code repository - offer additional features and capabilities not available with Team City alone.
TeamCity has greatly improved team efficiency by streamlining our production and pre-production pipelines. We moved to TeamCity after seeing other teams have more success with it than we had with other tools.
TeamCity has helped the reliability of our product by easily allowing us to integrate unit testing, as well as full integration testing. This was not possible with other tools given our corporate firewall.
TeamCity's ability to include Docker containers in the pipeline steps has been crucial in improving our efficiency and reliability.
