4 ms·

I myself love monolithic. But the CI is a mess. I'm using Jenkins. So right now I don't have a way to force build specific directory :(. It build entire thing

I myself love monolithic. But the CI is a mess. I'm using Jenkins. So right now I don't have a way to force build specific directory :(. It build entire thing :(. Anyone knows how to solve these problem? I have a Rails app, Go services, iOS, Android all in same repo.. It's interesting that we're moving into a microservice architecture but we try to consolidate the code base into one.

oweiler 8y ago
Wouldn't git modules solve your problem? You'd have to have multiple repos for each service though.
- ses1984 8y ago
  IMO this is the worst of both worlds.
  - shouldnt_be 8y ago
    Nice explanation
- kureikain 8y ago
  Gitmodule is really sucks when we have to bump a bunch of them.
nickspicer 8y ago
We do this inside a Jenkinsfile, slightly annoying if your actual pipeline is broken and needs editing as you also need to do a fake edit to the application, but works 95% of the time for us. def databaseChanges = sh returnStdout: true, script:"git diff --name-only HEAD^ HEAD database" def etlChanges = sh returnStdout: true, script:"git diff --name-only HEAD^ HEAD etl" def apiChanges = sh returnStdout: true, script:"git diff --name-only HEAD^ HEAD api"
ses1984 8y ago
Assuming each one of the rails app, go services, etc, are in their own subdirectory, hash the contents of the subdirectory and use that as one of the tags that is stuck on the artifact. Look up the tag in your artifact store. If it doesn't exist, run your build scripts.
- kureikain 8y ago
  wow, haven't though of it. Sound like very good strategy. Going to try it out.
ceronman 8y ago
That's interesting. In my experience, one of the major advantages of a monorepo is precisely CI. In fact, only after we tried a Monorepo we finally experienced true CI. An example to illustrate this: You have a library X that depends on Library Y and application A that depends on X. Then when you make a change in Lib Y you want to make sure that the change doesn't break X or A. If A, X and Y live all in separate repositories with separate CI pipelines, then this is hard/cumbersome to solve. In a Mono-repo, if you use a build system like Bazel, it's very easy. I believe when you say that your Jenkins setup is a mess, we experience a similar situation with GitLab CI. But I think it's important to realize that CI stands for "Continuous Integration". And running pipelines for every individual repository is not really testing integration, it's just testing an individual component. The solution is to use Bazel or similar. Then you will have proper CI.
coldcode 8y ago
We have multi repos, in fact dozens of them, that make up our public facing mobile apps. Our CI is a disaster as we have way too many simultaneous releases in flight at the same time (up to 7), not sure how this would even work in a monorepo.
dec0dedab0de 8y ago
You could have it check if those directories changed since the last build. Then it only builds what youve recently worked on
NicoJuicy 8y ago
I actually have easy deployment with monoliths with Jenkins in dot net. Deploying, creating nugets, .. And conditional deploying ( eg. Update external libraries only. I'm production, it's not continuous, but in beta and alpha it is.

oweiler 8y ago

Wouldn't git modules solve your problem? You'd have to have multiple repos for each service though.

ses1984 8y ago
IMO this is the worst of both worlds.
- shouldnt_be 8y ago
  Nice explanation
kureikain 8y ago
Gitmodule is really sucks when we have to bump a bunch of them.

nickspicer 8y ago

We do this inside a Jenkinsfile, slightly annoying if your actual pipeline is broken and needs editing as you also need to do a fake edit to the application, but works 95% of the time for us. def databaseChanges = sh returnStdout: true, script:"git diff --name-only HEAD^ HEAD database" def etlChanges = sh returnStdout: true, script:"git diff --name-only HEAD^ HEAD etl" def apiChanges = sh returnStdout: true, script:"git diff --name-only HEAD^ HEAD api"

ses1984 8y ago

Assuming each one of the rails app, go services, etc, are in their own subdirectory, hash the contents of the subdirectory and use that as one of the tags that is stuck on the artifact. Look up the tag in your artifact store. If it doesn't exist, run your build scripts.

kureikain 8y ago
wow, haven't though of it. Sound like very good strategy. Going to try it out.

ceronman 8y ago

That's interesting. In my experience, one of the major advantages of a monorepo is precisely CI. In fact, only after we tried a Monorepo we finally experienced true CI. An example to illustrate this: You have a library X that depends on Library Y and application A that depends on X. Then when you make a change in Lib Y you want to make sure that the change doesn't break X or A. If A, X and Y live all in separate repositories with separate CI pipelines, then this is hard/cumbersome to solve. In a Mono-repo, if you use a build system like Bazel, it's very easy. I believe when you say that your Jenkins setup is a mess, we experience a similar situation with GitLab CI. But I think it's important to realize that CI stands for "Continuous Integration". And running pipelines for every individual repository is not really testing integration, it's just testing an individual component. The solution is to use Bazel or similar. Then you will have proper CI.

coldcode 8y ago

We have multi repos, in fact dozens of them, that make up our public facing mobile apps. Our CI is a disaster as we have way too many simultaneous releases in flight at the same time (up to 7), not sure how this would even work in a monorepo.

dec0dedab0de 8y ago

You could have it check if those directories changed since the last build. Then it only builds what youve recently worked on

NicoJuicy 8y ago

I actually have easy deployment with monoliths with Jenkins in dot net. Deploying, creating nugets, .. And conditional deploying ( eg. Update external libraries only. I'm production, it's not continuous, but in beta and alpha it is.