Jenkins

I've had good experiences moving from Supervisord to using systemd for managing processes, especially for setups involving RabbitMQ and Symfony. Systemd not only integrates well with the system, offering better control and management, but it also simplifies logging through journalctl and handles automatic restarts seamlessly.

Here's what I did to make the switch: - Craft a Service File: I wrote a .service file in /etc/systemd/system/ to describe my service. It includes details on how to start and stop the process, among other things. - Set Up Service Behavior: Inside this file, I specified commands like ExecStart for launching my process, Restart to ensure it always restarts after failure, and set the User to define which user runs the process. - Enable and Launch the Service: With systemctl enable my-service.service, I made sure my service would start on boot, and systemctl start my-service.service got it running right away. - Manage and Log: Whenever I needed to check on things, journalctl was there for logs, and systemctl helped me manage the service (like checking its status or restarting it). - Switching to systemd resolved the disconnection issues I faced without needing any workarounds like restartingI've had good experiences moving from Supervisord to using systemd for managing processes, especially for setups involving RabbitMQ and Symfony. Systemd not only integrates well with the system, offering better control and management, but it also simplifies logging through journalctl and handles automatic restarts seamlessly.

Here's what I did to make the switch: - Craft a Service File: I wrote a .service file in /etc/systemd/system/ to describe my service. It includes details on how to start and stop the process, among other things. - Set Up Service Behavior: Inside this file, I specified commands like ExecStart for launching my process, Restart to ensure it always restarts after failure, and set the User to define which user runs the process. - Enable and Launch the Service: With systemctl enable my-service.service, I made sure my service would start on boot, and systemctl start my-service.service got it running right away. - Manage and Log: Whenever I needed to check on things, journalctl was there for logs, and systemctl helped me manage the service (like checking its status or restarting it). - Switching to systemd resolved the disconnection issues I faced without needing any workarounds like restart jobs. It felt like a cleaner, more reliable approach.

JMeter is best suited for generating user load with built-in integrations. To generate that type of load, you’ll need to choose a cloud-based solution that runs JMeter, such as BlazeMeter or RedLine13. They support JMeter for testing RESTful APIs and there is a plugin specifically designed for MQTT. You’ll want to look at subscription options and costs to run at that great a load.

There are JMeter plugins you can configure for all sorts of profiling including persistence of connections. And third-party plugins that you can add as JAR files to your load test, such as this one specifically for Kafka. JMeter also has good support for configuring authorization headers.

With regard to CI/CD integration, both support Jenkins. RedLine13 has a custom Jenkins plugin and allows for resources for tests to be sourced from GitHub and other places like AWS S3.

I never use Tower, but I can recommend Ansible Semaphore as alternative to Rundeck. It is lightweight, easy to use and tailored for work with Ansible.

Hi, since you are already using Red Hat Openshift so you are aware of how good Red Hat products are. Going with Red Hat will give you more flexibility considering points that you have mentioned. Red Hat products are based around an approach of providing flexible and scalable architecture where you can easily manage your instances in a cloud native manner. You can also have a look at Red Hat Ansible which will provide your team to run Infrastucture as a code. For Jenkins, you can easily set up and automate the things based on manifests file. You can also automate the things based on multiple environments.

Hello Xie, here are the tools am using for my entire CI/CD pipeline : 1-Jenkins (make sure to install Blue Ocean plugin) it will make your life easier and it's user friendly. 2-Gitlab as a container registry for my docker images (you can use it for code source too of course) 3-Github for version control and source code (make sure to benefit from webhooks to interact with your jenkins server). 4-Ansible : in order to automatically execute shell commands on different machines local and remote. 5-As always i recommend Kubernetes to manage containers (that's what am using) Best of luck

Octopus is continuous deployment tool, while jenkins is general-purpose CI/CD platform, normally Octopus is used after (integrated with) Jenkins.

Normally octopus is compared with Harness and Spinnaker

Which one is better always depends on your use case? try one and use another tool to compare, you will get it by yourself.

Hi Kavita. It would be useful to explain in a bit more detail the integration to Jira you would like to achieve. Some of the Jira plugins will work with any git repository, regardless if its github/bitbucket/gitlab.

You must have gone through multiple thoughts on how to handle the requirement, but the biggest problem that I am able to see here is a dependency on a certain platform for executing Powershell scripts. Next is being a developer will never suggest having Powershell or bash as a backend of your system until it is related to some IoT Stuff. In place of it, I would rather suggest you use Infrastructure as a Code that comes with terraform or Ansible or as your application is based on Azure so u can use Azure Resource Manager too.

Adding to it for making config or attaching a trigger to these infrastructure controllers, you can use lightweight stateful APIs with the help of flask or express or go-mux, to keep track on the progress of deployments.

I'd recommend against using PowerShell as a backend, unless your logic is very simple (maybe less than 100 lines total). I've worked with a huge framework written in PowerShell, and we hit a lot of bugs. (Some of the issues traced back to bugs in the PowerShell runtime itself! Most of the team who owned the PowerShell framework admitted that if they could reimplement it they would pick a different language.) If you're already using Python, then I'd recommend using Python for other backend code -- or a more structured .NET language, like C#.