I want to design a Spring Boot REST API using GitLab's API to pull the specific repository branches from GitLab.
Requirement
We have been working on a big project and that project functionality is getting split into nearly 15 microservices and we have a GitLab repository for each microservice to organise the code remotely. And each repository has many branches like
master branch
dev branch
prod branch
And when we do have a prod release by that time we are raising merge request from dev branch to prod branch by logging into GitLab. And same practice we are doing for all other microservices which need prod deployments. So, here we think rather logging into gitlab and raising merge request from one branch to another branch every time.. we would like to write some Spring Boot service which consumes GitLab services like pulling specific repo details like its branches and other info and then raise merge request from one branch to another branch
So here we mainly looking for two operations one is pull the repository branch details and once pull the branches then raise a merge request from one branch to another branch.
Pull repository branches
Make branch merge request
And we are ready with React UI at client side and looking at REST services with above operations.
As I haven't worked before on such API implementations, I am interested in how achieve the same.
You will want to look into the use of Spring's RestTemplate from the spring-boot-starter-web project. You can use the RestTemplate to call the GitLab APIs to perform your operations on each of the repositories.
Now, there is a lot of information on this subject and a full write-up would be enormous so my suggestion would be to read through Spring's guide on building REST APIs. Baeldung also has a nice little introduction to the rest template that can be found at https://www.baeldung.com/rest-template
Related
We are in process of versioning microservice for parallel deployments.
During this process we are versioning the entire service by following git release branches i.e. cut release branches from main during the release and maintain release branches as supporting that specific release.
Now we have a problem we are trying to solve which is Spring Cloud configuration.
We have external config server deployed which gets the configuration from Git repo.
What is best way to version the configuration properties or yaml files?
We have brainstromed different ideas like
single git repo and multiple branches for different version for e.g. service-v1 gets config from v1 branch and service-v2 gets config from v2 branch
single git repo and single branch but use prefix key and suffix as version for e.g. key1.v1=v1, key1.v2=v2
Please let me know what is better/clean approach or any best practices for solving this versioning of of configuration.
Thanks
I am using Spring Cloud Config Server first time and have a basic query.
Spring Config server externalises the configuration to a separate git repository.
Why would I create a separate repository just for the configurations?
Is not it advisable to have mono repository with all application code and configurations in a single repo than creating a separate one just for configurations.
We have multiple micro services all present in the same repository. Should not the config server to be one of the micro service present in the same repository where the other application code is?
So, in my multi-module gradle project, I can make config-server as one of the module and give the same repository name as git backed url in config-server. Is this advisable? If yes, where should I keep the configurations in config-server? Inside resources?
Thank you.
When working with microservices it is advisible to have one repository for each microservice. The config server is a microservice as well, therefore it should be put in a separate repository.
Each microservice should have its own independent code repository and your application configuration should never be in the same repository as your source code.
You can read more about this here: Heroku's The Twelve-Factor App. Here you can find 12 best practices to use when building microservices, but for this question I recommend looking at
1st factor: The codebase
3rd factor: The config
I have a spring boot project with 4 microservices (Eureka service registry, Config server, a Zuul gateway and a userservice) in one repository with a parent project where I have a docker-compose.yml which reads the Dockerfiles in the microservices project and uses the "application-docker.yml" and "bootstrap-docker.yml"
What I'd like to do is to trigger a jenkins pipeline after a commit in git so that it will compile and deploy the microservices in Docker. Eventually I'd like to have a production configuration that deploys the images in Kubernetes maybe AWS.
Now, in order to work, the microservices need to start in order:
configserver
eureka service registry
gateway , etc..
What is the best practise?
If I have separate repositories per microservice, I think I can figure it out. It should be easy to deploy a single microservice assuming that configserver and eureka service registry are already up and running, in reality they should never change.
If I have a single repository, and I keep developing new microservices, do I need to have separate jenkins file per microservices or can I have a jenkinsfile in the parent project and use docker-compose?
How does it work? Any articles online that can help (couldn't find any). Does it make sense?
Or do I need to look at Jenkins X ?
Thanks!
I would recommend using separate repositories for each microservice. You use microservices to prevent monoliths and have small well-defined services; it only seems appropriate to also separate them by space i.e. store them in separate repositories (making it for example easier to reuse one).
You would then have to provide a Jenkinsfile in each repo. These would be mostly identical.
If you want fast release cycles you could automatically deploy a single service upon release.
Alternatively you could use an additional release train module that handles the full deployment.
In both cases I would use a docker-compose file that handles the interconnection between the services.
You can enforce the right order by using 'depends_on, links, volumes_from, and network_mode: "service:..."'. For a full reference see the docker documentation.
If you want to keep your single repository your Jenkinsfile(s) would have to be quite hacky, I suppose... After each commit you would either
build all modules --> monolithic behaviour
somehow determine which modules have changed (e.g. looking at the git log) --> same behaviour as with multiple modules but very hackily
The Docker-Compose File
If you want to release all modules at a specific point of time you could use a Release Train module where the docker-compose.yml resides next to a Jenkinsfile. Then when you want to ship your application you can start this Jenkins-job.
If you want to ship each service as soon as it is released, independently from the others, you would need to access the docker-compose.yml from each module. You could do this manually (since the files won't change too often) or create a docker module that you use as a git-submodule in all your services.
We use a generic docker-compose.yml for this, where every version is replaced by a variable:
example-service:
image: example.service:${EXAMPLE_SERVICE_VERSION}
Then to start that specific service in jenkins we use the command
export EXAMPLE_SERVICE_VERSION=1.1.1
docker-compose -p example-project -f docker-compose.yml up -d example-service
We are using jBPM EAP 6.4 version. We are developing the JBPM workflows and rules using business central console tool.
We want to implement Continuous integration in our project. How can we implement the CI if we use Business central console for our changes ? Normally Jenkins (other build server) listens repository server for changes, as soon as developer pushes the changes to repository, immediately it will trigger the build and deploy.
But in our case we are developing everything using the console.How to achieve CI in this special case or any recommended approach to implement CI in jBPM ?
Can you please suggest..
Thanks
Just a pointer,
The work bench (business central control) is pointing to a git repository (by default), so essentially, when you are interacting to the work bench, you are doing actions very similar to a normal scenario, that is, where a developer commits to a git repository.
User documentation jBPM - VFS repository
Hope this gives a direction.
Repositories in Business Central use virtual file system based on Git and each time you save something in one of the editors a commit is made. You can create a Git hook on your repository which will trigger some action after each commit.
Dear All,
I'm new to GIT and i want to move from SVN to GIT, in my application I'm using web services, for each web service i have bundle for API, bundle for IMpl, and another for service.
I want to make branches for each web service to contain service and WS-Impl. and another branch that will contain all WS-API. the reason is to limit access to the code.
If you want to apply access rights, then i would suggest to put the API projects in separate Git repositories. Branches aren't there for this case. So you would have one repository for the API project and one repository for Impl and Service.