I have two projects:
CompanyAManagement
CompanyBManagement
And for both projects, I would have a repository "frontend" and "backend".
However, after I have created the project "CompanyAManagement" and created both repositories in it, I can no longer create repository with the same names in my second project.
What would be the best practice to get along with this issue?
I come from gitlab where I have groups where repos are inside, this is possible there.
In Bitbucket Cloud it's not possible to create Repository with same names in different Projects as well.
That's the downside of Bitbucket Cloud which I found in past.
And if you try to do so, it will remove repositories from first project and add in in it second project.
Thanks
Related
I am planning to create a Project in Jenkins and I am thinking of using Organisation folder for that.
Since the project has severals applications (mobile app with backend and frontend parts) I have several repos that will need to be separate jobs.
My question here is is it possible (or is it a good/bad practice as well) to put all Jenkinsfiles for all the apps in one separate folder (called Jenkinsfiles for example) from where I will invoke the corresponding file?
Until now I have been placing Jenkinsfile in the repo where is my app that I am doing the build but now, with whole project, I need to decide which approach to take so I would appreshiate any contribution in decision making
If you are asking "can it be done" the answer is Yes, most likely - but how will you manage which Jenkinsfile is being run?
As I see it, the main idea is to have the Jenkinsfile next to the code being deployed.
If you have several applications in your project repository, maybe you could have separate repositories with "just" the Jenkinsfile and deployment config. You could then use the Jenkinsfile in the main code repo to trigger all the sub-jobs.
I have done something similar, and have seen several companies with separate jobs for prod/user-test that require separate permissions to be triggered as well
I am looking for a configuration idea for jenkins.
I have a react native app that builds for iOS and android. Source code is stored in the repository "A".
Configurations (app flavours) are stored in the repository "B". They are added every day or two, sometimes existing ones are updated, each one has a version.
What is the best approach?
The goals are:
Start a build when either repository "A" or repository "B" is updated
If repository "B" got updated but specific flavour config did not change (same version) - skip testing/building.
The questions:
Is it better to create 1 job per flavour or loop through all configs in 1 job? It seems like creating jobs dynamically is a more flexible solution.
What's the best approach to skip rebuilding existing flavours if specific configuration didn't change after a repository update?
Are there any plugins you could recommend to achieve my goals?
We are going to be migrating an existing BizTalk codebase into TFS 2015 update 2. We would like to use GIT rather than TFVC for version control.
I have a problem getting my head around the repo to project relationship. I would like to run independent TFS projects for managing discrete pieces of work that align with "projects" as run by the business. Instinct tells me that I should create a branch for such projects but each TFS project seems to need its own repo?
If I stick with a single (BizTalk) TFS project, I will be able to create a branch for each business project but the work items will all be mixed together. This would make helpful reporting tools such as the burndown chart useless.
I guess the other option is to run multiple TFS projects each with their own repo and then manually merges between the repos? Maybe have a "Main" project and use its repo as the main branch of the project repos?
How are people managing this problem?
First note that inside a Team Project you can create several Git repositories.
Also, remember that Git branches have repository scope, it is not a directory like in TFVC (which it is not like Git at all :-) ).
Then if you want to migrate to Git, you need to modularize your projects. Once you have a modular code base, for each module you should create a Git repository. From each repository you should be able to build and publish a Nuget package. Then resolve inter module dependencies by resolving dependencies by means of Nuget package.
No need to merge anything from repo to repo or from module to module :-) You only need to merge from branch to branch inside the same repository.
The better way is that you can create multiple repositories in GIT Team Project.
Regarding work items, you may create multiple teams and areas, then put work items in different areas and change area per to requirements (the teams can have the same area).
There is a blog that may benefit you: Many Git Repositories, but one Team Project to rule them all
I'm developing a private webapp in JSF which is available over the internet and now reached a stage where I wanted to introduce CI (Which I'm fairly new to) into the whole process. My current project setup looks like this:
myApp-persistence: maven project that handles DB access (DAOs and hibernate stuff)
myApp-core: maven project, that includes all the Java code (Beans and Utils). It has a dependency on myApp-persistence.jar
myApp-a: maven project just with frontend code (xhtml, css, JS). Has a dependency on myApp-core.jar
myApp-b: maven project just with frontend code (xhtml, css, JS). Has a dependency on myApp-core.jar
myApp-a and myApp-b are independent from each other, they are just different instances of the core for two different platforms and only display certain components differently or call different bean-methods.
Currently I'm deploying manually, i.e. use the eclipse built-in export as war function and then manually upload it to the deployments dir of my wildfly server on prod. I'm using BitBucket for versioning control and just recently discovered pipelines in BitBucket and implemented one for each repository (every project is a separate repo). Now myApp-persistence builds perfectly fine because all dependencies are accessible via the public maven repo but myApp-core (hence myApp-a and myApp-b, too) fails of course because myApp-persistence isn't published on the central maven repo.
Is it possible to tell BitBucket somehow to use the myApp-persistence.jar in the corresponding repo on BitBucket?
If yes, how? And can I also tell BitBucket to deploy directly to prod in case the build including tests ran fine?
If no, what would be a best practice to do that? I was thinking of using a second dev server (already available, so no big deal) as a CI server but then still I would need some advise or recommendations on which tools (Jenkins, artifactory, etc.) to use.
One important note maybe: I'm the only person working on this project so this might seem like an overkill but for me the process of setting that up is quite some valuable experience. That said, I'm not necessarily looking for the quickest solution but for the most professional and convenient solution.
From my point of view, you can find the solution in this post-https://christiangalsterer.wordpress.com/2015/04/23/continuous-integration-for-pull-requests-with-jenkins-and-stash/. It guides you step by step how to set up everything. The post is from 2015 but the process and idea are still the same. Hope it helps.
I have two apps/projects - one for customers and one for workers. Both projects have the same back-end API related code, the same business-level objects, the same custom GUI controls and some functionality. I want to replace the identical code with the shared one. For example to move this code to a separate repo.
Since both projects are under development everything (including shared code) will be changed very often. Shared code will be usually updated as a part of one of these two projects.
What is the best way to share the code between two projects if I need an easy way to frequently update it?
My ideal use case will be the following:
I change the customer project (customer and shared code).
I commit and push new changes to the customer repo and to the shared code repo.
I open worker project, do pull for the shared code and then update worker code if it needs to reflect shared code changes.
P.S. Qestions Differences between git submodule and subtree and GIT Nested repositories: Composer vs. SubModules vs. Subtree vs.? have very good answers but it is still not clear what should I choose if I need an easy way to frequently update shared code.
I would use a git submodule personally, it's a very good link to a shared codebase that is itself a git repository that can be managed separately without being tracked in your other projects.
You can use git submodule foreach git pull origin master on both the client and worker side to pull in changes when the shared library is updated.