Today, if you're aware of the CI/CD requirements, then it's fine. Unless you know how to create the pipeline, it would be tough. The one I'm using is already set. So I can implement it immediately. If there is a deviation from that, then it will be a little tough, I would need to Google to find the solution. I can implement it.
When you're using it, it's automatically deployed. In a normal application, it used to provide a single application. In this proprietary thing, it is just now it used to provide in the scripting tag, you need to provide Spring Boot.run, and that server code. So that unit is forwarded. In Copilot, you need to mention which nodes you are going to configure. So you need to provide all the port numbers and then deploy there. It will automatically deploy everywhere.
The deployment is easier when you're handling multiple deployments. So, I don't need to node application unit for node, update, and everything everywhere. But it's also in the engine we can do there.
Once you set up everything, it is automatically handled. But once the setup is done, it's done.
GitHub Copilot code suggestion capabilities: It's always good. When you're doing any deployment, the suggestions are always welcome. You don't need to remember everything. You can pick from the solutions provided.
One thing I noticed is that normally, in CI/CD pipelines, we put:
- the Jenkins path,
- the Git repository paths, and
- the number of reports we are going to deploy.
If we had an automatic system, an automatic page to do all these things, it would be easier. Not a configuration, but a page. If you have that kind of page, then Copilot can help all the developers. This is my individual preference. It can be there, it may not be. Maybe I'm not able to explore those issues, but that is one thing I noticed.
Currently, we need to map everything. We need to provide the Git card and where we need to deploy. If it is pre-prod, stage, or production, we need to map it separately. If we had some kind of program and could take it from the application of properties file, it would have been great. We configure everything in separate files.
Even for development, staging, and production environments, we need to make separate files for each. If you have some mechanics to automate that, it would be great. It's for the entire system. Their system is like that. You need to prepare separately for every manage. So if you have one utility to make all those alternates, it would have been great. A UI would enhance the developer experience and streamline the CI/CD process.
You need to configure it separately for each environment. If everything is in a dropdown, it could be directly included. It will automatically connect to your dedicated agent. But it is okay. As of now, it's working fine. It's just manually maintaining that data. It worked fine. No issues. That is the only suggestion I have.
TL;DR:
For different environments, like production, stage, and development, if we can have a single point, like one, two, or three instead of opening for each, that feature would be helpful. We have numbers for certain regions, but again, the developer and the team should remember which number is for dev, stage, and prod. That could be easier for maintenance.
The administrator doing the CI/CD pipeline should remember that number. It can be easier for any AI tool to do that. Instead of putting the phase in the configuration, if you put in a AI tool, it is easier for the system to manage.
I have been using it for three months.
It's scalable.
In the last team that we had around 13 members, everyone never faced any issues when using Git merge and Git commit. You have a separate Git repository, and you just need to know how to use it. The only thing is, our case of sessions should be organized, and the resources should be proper.
You want to see what everything the account does. I do everything with a command prompt, not using any Git GUI. You'll get the GUI application for your commit and such. It's fine.
Deployment time: If the database scripting and the data center information are ready, then it will take one or two hours. It's a server configuration. Two to three hours of work.
Deployment resources: I can also do it. It doesn't require multiple people. If the software is ready and everything is fine, then only one person can do everything. That is what a full-stack developer means. If you are a full-stack developer, it means you can handle all the data-related tasks and services. I'm a full-stack developer, so I'm ready to do that. I should have the capability to do everything on the website.
We have a separate team to do that. They will do the things for us. From my side, I just raise a ticket in Jira support, and then they will take the ticket and implement it. The installation and configuration is a separate process because in each organization, they have separate monitoring systems.
There's a separate team to make those things happen for me.
Overall, I would rate the solution a nine out of ten. The only suggestion is to enhance Copilot's ability to assist developers with infrastructure as code tasks.
Like, while using CI/CD pipeline, when I use YAML files, so it could just support the port number. That will improve the feature. But the developer should be aware of the feature.