Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
revmoo
May 25, 2006

#basta
We drank the Atlassian cool aid and I configured CI using Bamboo backed into Stash. It's pretty swank. The only thing I don't love about it is the pricing is a little aggressive. Coming from Jenkins though, I like the UI a lot better.

Adbot
ADBOT LOVES YOU

revmoo
May 25, 2006

#basta
So we're moving from Bamboo and stash to Gitlab.

I just setup Gitlab-ci and pushed a successful test deploy. Then I realized that there's absolutely no interface at all for managing builds and environements. What the gently caress?

I get that I can set up tagged releases for prod pushes and use branches to dictate dev server pushes, but this is a HUGE pain in the rear end. We normally push builds around to various test/staging/beta/prod servers willy nilly and not having an interface to do this is likely to make my pull the plug and use Jenkins or something instead.

Am I missing something or does Gitlab-CI really have no interface at all for managing deployments?

revmoo
May 25, 2006

#basta

revmoo posted:

So we're moving from Bamboo and stash to Gitlab.

I just setup Gitlab-ci and pushed a successful test deploy. Then I realized that there's absolutely no interface at all for managing builds and environements. What the gently caress?

I get that I can set up tagged releases for prod pushes and use branches to dictate dev server pushes, but this is a HUGE pain in the rear end. We normally push builds around to various test/staging/beta/prod servers willy nilly and not having an interface to do this is likely to make my pull the plug and use Jenkins or something instead.

Am I missing something or does Gitlab-CI really have no interface at all for managing deployments?

Followup; no, Gitlab-CI really doesn't have an interface for managing deployments.

Went ahead and migrated to Jenkins, glad I did. With some extra themeing work I now prefer it to our previous Bamboo setup.

revmoo
May 25, 2006

#basta
Honest question as I'm a bit of a noob; why would you deploy using docker? Isn't that a bit overkill? I get managing infrastructure with it but I don't see why you'd push out whole containers every time your app gets an update.

revmoo
May 25, 2006

#basta

MrMoo posted:

Container sizes commoditized the VM image so that it is a low cost transaction. It also provides a guarantee of idempotency in the rollout as patching can always fuckup.

It seems simple to just wave a hand and say it's easy, but I can see a ton of pitfalls; session management being a huge one. Right now our deploys are less than 1ms between old/new code and we're able to carry on existing sessions without dumping users. I don't see how Docker could do that without adding a bunch of extra layers of stuff.

revmoo
May 25, 2006

#basta

FamDav posted:

Are you using persistent connections? Storing session data local to each host? How many instances of your application are you running?

I'd have more specific answers depending on the particulars of your software, but my general answer is that it sounds like you're deploying for the success case rather than the failure case. What if your deployment takes too long to start up, or never comes back online? And what about things that happen otherwise, like hardware failures?

Deployment is a great way to test that your service is resilient to some bog standard kind of outages. Depending on host fidelity and near instantaneous switch overs is dangerous because it will break. It's also orthogonal to docker itself.

I'm quite happy with my deployment methodology and I'm not interested in changing it. I would definitely like to explore Docker for infrastructure management but I couldn't imagine using it to deploy code. I'm really just curious why anyone would do it that way. I guess it would make sense if you built your application to scale massively from the very beginning rather than an organic evolution, but that's incredibly rare in this industry. Like, my understanding is FB deploys a monolithic binary (using torrents IIRC), but I don't think even they are pushing whole machine images at this point.

I'm not really understanding your statements about deploying for success or failure. My deployments are resilient, and have a number of abort steps. We saw the occasional failed deploy bring down prod once or twice a long time ago but we re-engineered the process to work around those issues and haven't had issues in a loooooong time. Nowadays if a deploy fails, that's it, it just failed and we address the issue. Prod remains unaffected. I haven't seen prod brought down from a deployment in ages. I can't imagine why using Docker would make these sorts of issues better or worse, if anything you're just facing another spectrum of possible issues.

quote:

Depending on host fidelity and near instantaneous switch overs is dangerous because it will break. It's also orthogonal to docker itself.

I have no idea what this means.

revmoo
May 25, 2006

#basta

Paul MaudDib posted:

I've never used TeamCity but I've used Jenkins and Bamboo and I thought Jenkins was steaming garbage in comparison to Bamboo. Any given task takes probably 5 times as long to configure.

I've used Jenkins a few times and finally this time around fallen in love with it. It takes a lot more hacking and configuration, but once you have it running it's awesome. I think the best thing about it is that its popularity means there is a plugin for everything.

One strategy I've adopted is to basically offload all deployment tasks to external scripts. That way Jenkins isn't actually doing much of anything. My tasks setup is basically (1) Pull selected branch, (2) Call deploy script. Jenkins is simply the command-and-control rather than doing the heavy lifting. This coincidentally makes it really easy to migrate to a new deployment system. It also helps with debugging because I can manually run 99% of the process without touching Jenkins.

revmoo
May 25, 2006

#basta
Okay

revmoo
May 25, 2006

#basta

the talent deficit posted:

how do you envision docker helping with infrastructure management?

I need a new server node spun up. I provision the VM and deploy a docker image to it. Then I deploy our app to the node.

Is this not the intended use case for Docker?

Adbot
ADBOT LOVES YOU

revmoo
May 25, 2006

#basta

the talent deficit posted:

no, not really? what is in the docker image in this case? a service like fluentd or postgres?

Yeah, like our whole stack minus application code and db contents etc.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply