I am currently working on a Linux bash script to deploy a specified branch of my git project on my website : the develop branch to a test subdomain and the main branch to the main domain.
To do so, I ask for a user input (the branch name) and execute my set of commands to deploy on the right subdomain. The only problem I have is that, these operations involve moving certain parts of the project and so, I don't really see how I could deploy the two versions. To me, the two options are :
Have two repositories to be able to use the two branches separately. This would work fine. BUT, that means I will use double the amount of space which doesn't seem right. (and my project is quite big)
Find a way to deploy two branches of one same repository on two different subdomains independently. Meaning that updating one doesn't update the other.
How could I use one repository from which I deploy two branches on two different subdomains ? Is it even possible ?
I thought that I could just switch to the choosed branch and then update but that changes the project for both versions, which seems logical now since the whole project is accessed.
Related
I'm wondering if there is some good way to make CI/CD for single git repository that contains many projects. I often work with microservices, but I always preferred to have separate repo for each project and thanks to that I had separate pipelines for each repo. Now I'm in situation where all microservices are in single repo and I would like to know if there is some good way to make it work. The question is general because I don't have any CI tool right now, probably going to use Gitlab CI or Jenkins if I'm gonna need something more complex.
Yes it is possible, but you need to understand that your pipeline can be too big depending how many microservices you have in this repo
look here: https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic
you are able to add a lot of only/except conditions to avoid or force some specific steps
example
build only if folder x is changed
test only if microservice x was built.... except if branch is example
I'm beginning to understand how Heroku works, but haven't yet used a pipeline. I have an app I'm working on that is near its first production version. I'd like to begin using pipelines.
But I don't understand how to begin. What do I need to do to make a copy of the current app and have that copy be in the development stage and make another copy for the staging stage? Do I fork my git repository twice and add each one?
I'm trying to take this one step at a time. I don't need GitHub integration yet. This is a small project and will not have any pull requests for quite some time, if ever. I'm only interested in the ability to develop, stage and release in the three stages offered by Heroku.
While pipelines do use multiple apps, they should use the same git repository with different remotes. Heroku's help page helped me understand that the process is to link the repository to each app different remote names and then push to the remote that I'm currently working on.
We have 3 projects and a 4th one that is shared among them.
A multiple project in gradle requires one to create a wrapper project and include all the sub projects in it.
Each of our sub projects are being worked on by different team members and we use git as an svn.
Our concern before going into gradle is the fact that we will only have 1 git repository that consists of the wrapper project with all sub projects instead of 4 different repos, each for each sub project.
1) Are we missing something?
2) Is it possible to create 4 repos on a multi project?
3) One of our requirements is to deploy a single war (for example only webapp #1 out of the 4)--does using the multi project template make it possible?
ad 1) You have some choices:
Use a single Git repo.
Use multiple Git repos and exchange artifacts via a binary repository (e.g. Artifactory), with artifacts being produced on a regular basis by CI jobs.
Use something like Github submodules to create a "virtual" overall Git repo (wouldn't recommend this one).
ad 2) Gradle doesn't really care how many Git repos the build is comprised of, as long as everything that settings.gradle points to (at least all build scripts) exists on disk when the build starts. Of course it may be inconvenient for developers (and CI admins) to juggle multiple Git repositories and put them in the right (relative) locations.
ad 3) Yes.
I stumbled across this question on the same quest, and only later somebody pointed out another option to me (it's really a variant of the third choice listed under ad 1 in https://stackoverflow.com/a/20678444/1016514), which seems like an elegant hack:
You keep the subprojects in separate Git repos, and from within your root project point to them by setting the respective rootDir properties. This requires a fixed checkout layout, obviously, but that would usually be the case anyway.
The approach is described here: https://medium.com/codequest/gradle-multi-project-build-substituting-jar-dependencies-with-local-projects-4a5323f8680b
Update with Gradle 7.3+: this will now yield a warning, and likely not work after some point in the future:
Subproject ':xyz' has location '...\xyz' which is outside of the project root.
This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0.
Consult the upgrading guide for further information:
https://docs.gradle.org/7.3.1/userguide/upgrading_version_7.html#deprecated_flat_project_structure
I'm wondering how teamcity handles the checkout for multiple configurations. They recommend to use the Auto option where the checkout directory is shared between all configurations. Then, what happens if one configuration is currently building, and another is going to checkout? I think I really have to set different directories for these? Also if different configurations have run, their output gets overwritten by each other.
As a side-note: we have one project with three configurations, namely Continuous, Nightly and Weekly. Maybe I have to split them into different projects?! But on the other hand I think different projects are more suitable for different branches or so.
Teamcity won't ever run two builds on one agent at the same time, so you'll never have the case where two builds try to use the same directory at the same time.
But that aside, Teamcity will use a different directory for configurations with different VCS roots; it'll only share if they have the same VCS roots with the same checkout rules. But that shouldn't cause you any problems, if you set things up right.
Also if different configurations have run, their output gets overwritten by each other.
You shouldn't be relying on files being in that directory. If you need access to the files, you should publish them as artifacts, and set the build configurations that need them to have artifact dependencies on the artifacts.
As a side-note: we have one project with three configurations, namely Continuous, Nightly and Weekly. Maybe I have to split them into different projects?!
You shouldn't have to; why would you need to split them? They can run fine in the same project, but you can move them into separate ones if you prefer.
So I'm having a bit of a structure problem with my repositories. I hope you guys can give me a few pointers on how to go forward with this.
Setup;
I have one large web project, with several opensource solutions integrated. I have it all in a Bazaar repository.
Problem;
I want two or more "configs" of this site now, meaning the database and css/templates must be different. How do I branch of this properly? I don't want my "base web project" in two or more repositories.
Putting another config database in another repo is fine, but problem arise when I'm moving out the .css from the base repo.
A quick search for ".css" finds around 200 files. I could clean this up, but then I will have a integration hell whenever I update my opensource directories.
Idea;
My current idea is to have one basesite-repo without the css files, and another config-repo with the database for the basesite-repo and all 200 .css files.
This works fine whenever I want to checkout the site and set it up, two checkouts in the same directory. Should work, right?
But how do I solve it when I work on the site(meaning base+config) locally? having two branches in the same directory? I foresee that releasing bug fixes will be a pain...if its even supported(?)
How my idea structure could look like;
//base repo
<base site repo>
-<admin>
-index.php
-<user>
-index.php
...
-<component>
-<helper_v1.43>
-index.php
//config 1 repo
<config1-repo>
-<database>
-<component>
-<helper_v1.43>
-<template>
-main.css
-<admin>
-admin.css
...
-<user>
-<timemodule>
-<template>
-time.css
This problem must have been solved several times over the last decade. But still I'm pretty lost, so any guidance would be appreciated.
Many source control systems support the idea of branches containing largely identical files. It might not be a problem for you to have the base files in one branched repository.
You can also create branches just for the config stuff in the second repo. switch between branches before you apply your fixes.
Another approach, if you have any sort of build or checkout process, check out the two branches (or two repositories) of the config stuff to separate directories, and then copy the correct one to the right place during your build.