What product/components do you use and which version/fix level are you on?
10.5 IS packages
Is your question related to the free trial, or to a production (customer) instance?
Customer instance dev environment
What are you trying to achieve? Please describe it in detail.
We are doing local service development, all the developers having own IS local server to develop the new service and modify the existing services as well.
Our repository is hosted in azure repo, we can able to build and deploy using azure pipeline in our target IS server. But now the problem is not sure how to allow users to work parallel development for single service.
Let’s say we have service name called devops_flow_service, now the scenario is, we have two users they want to start their work using same service (devops_flow_service). Note since we are using repository based deployment each user they are doing development own git feature branches separately.
When the development is completed developer will raise the pull request from their own feature branch to develop branch, at this point time we will get conflict since they are touched same service without knowing each other.
can you please some one help me how to we can handle this for smooth parallel development with single service.
Do you get any error messages? Please provide a full error message screenshot and log file.
NA
Have you installed all the latest fixes for the products and systems you are using?
The technique you’re referring to is often referred to as “pessimistic locking”. I am not familiar with Azure repo, but other Git platforms do support it (e.g. Gitlab File Locking | GitLab). Having said this, it is sort of anti-git and I haven’t seen this technique used in years.
A webMethods service is equivalent to a method in a Java class. It should be small and extremely specific. If you have multiple developers attempting to modify the same service at the same time for different reasons, then it’s typically an indication that the service is not small or specific enough, and therefore, it should be refactored. It may also be an indication that commits are not happening frequently enough.
If you take care of ensuring your services are small and specific, your feature stories are also small and specific resulting in short-lived feature branches, and you have your developers committing frequently, I don’t expect you to run into many merge conflicts. If you do, however, then merging the changes should become simpler because you’ll be merging a smaller set of changes in smaller files.
Thanks for your time. Just thinking on it since azure repository don’t have option to lock the file from repository level, to overcome file locking can we try with git lfs lock <servicename> then we have push those services into azure repo until the service is completed. Please suggest this will help or not.
I honestly don’t know as I don’t have personal experience with this myself. As I alluded to in my previous post, locking source code files in a version control system is seen as an antipattern these days. If your services are modular enough and developers are committing and merging their changes into your main branch frequently enough, a conflict should be very rare, and when it does occur, you should be able to merge the changes (granted that merging Flow is not fun). In my personal opinion, it would be counterproductive to require file locking in your SDLC just to prevent an issue that may or may not occur.
If you still decide to go down this path and you cannot find a native git or Azure solution to your problem, one thing that I have seen people consider is to have a CI/CD pipeline that automatically deploys code to a shared development environment as its first target. You can use that environment as a means for developers to signal to each other that they are working on a particular service. For example, prior to starting changes to a service, a developer would lock that service in the shared development environment to signal to the other developers that he is working on that service. He would follow the process of creating a feature branch, making changes to it, committing those changes, and requesting a merge into the main branch. Once his changes are merged, he would unlock the service in that environment to signal that his changes are complete. To be clear, I’m not a fan of this approach either because it requires manual steps that are hard to enforce and that can be easily missed, but something you could consider if you must.
Another thing to consider is something that the author of the book Continuous Delivery recommended: develop directly in the main branch. In other words, instead of having the developers make their changes in independent feature branches, you have them all commit directly into the main branch. This forces developers to merge immediately, if there’s a conflict, and it encourages them (1) to keep their local copy up-to-date and (2) to commit frequently because they want to avoid complicated merges when they perform a push. For what it’s worth, I read this book ~10 years ago and the author may have changed his stance since then. Again… just an option but I’m not saying you should do this.
Thanks Again, i have tried with git lfs lock but it does not working as we expected, then i decided we have go with your approach as you said in previous command like developer must lock the services in shared environment first. Next user must create the feature branch from develop and do the code checkin and raise the pull request from feature branch to develop branch, after merging the changes, locked service should be unlock by the specific user.
