|
Dietrich posted:Ok so I'm trying to set up a TeamCity build agent for tackling Go. What am I getting myself into here? Go wants a GOPATH "work space" environment variable, but the build agent is going to be checking out everything into a workdir which won't have the requisite folder structure. Should I be scripting a move of all the sourcecode to the work space (after clearing it), triggering the build and the tests, and then pulling the resulting bin back to become an artifact? As wwb states you'll likely have to set the environment variables for go in a step before compiling. I've used a shell script that sets the Go workspace to the directory the Teamcity agent is running in, using the variables provided by Teamcity, then running go get and then go build. Things get easier when you vendor your dependencies: not running go get means it doesn't grab the latest from whatever your deps are. We used godeps for this (https://github.com/tools/godep) but there's some experimental versioning tooling built into the latest versions of go. Also gb (http://getgb.io/) is an option but I've no experience with that. Once things are vendored I think you can just run godep go build, possibly without needing the environment variable setting the go workspace. Then you can save the build artifacts easily. It's been a year since I last worked with TC and Go so details may be a bit off.
|
#
¿
Sep 30, 2015 05:07
|
|
|
|
| # ¿ Apr 30, 2024 05:29 |
|
|
Erwin posted:Does anybody have any strong opinions on Thoughtworks' Go? I was initially planning to move from Hudson to Jenkins (we went with Hudson back when it wasn't overshadowed by Jenkins), but I set up a test GoCD server and agents and I'm liking it so far. The thing I really dig is the pipeline visualizations, as we have dozens of separate repos in several different languages that all interact with each other, and in Hudson we do have some chaining set up, but not like it should be. I've seen companies looking at GoCD and ended up with Jenkins + a pipeline plugin due to the big question mark around GoCD's future. Not that Jenkins is superb, but it worked after tweaking and experimenting. Much better community around it. If Jenkins 2.0 gets traction it'd probably be the best solution.
|
|
#
¿
Nov 16, 2015 23:17
|
|
|
As far as I know, Terraform wants to own all state of resources which prevents using it with Cloudformation templates. Troposphere ( https://github.com/cloudtools/troposphere ) works well enough for making Cloudformation templates from Python code instead of hand-coding Cloudformation. The past few jobs we've checked in the Troposphere code to do infra as code. A few years ago I've used Route53 CNAMEs to do slow deploys. New stack comes up with a CNAME matching the existing one (fooservice.whatever.io). The old service has a weight of 100, new service has 0. Adjust the weights to the new stack and eventually remove the old service version's Cloudformation stack. This is a bit of an old way of doing things, but would work well for blue/green deploys. AWS CodeDeploy has rolling deploys and ECS does as well. I think CodeDeploy has more nuanced options available for deploys. This video from reinvent 2015 has good info: https://www.youtube.com/watch?v=A4NSyUbAEkw .
|
|
#
¿
Jul 30, 2017 00:42
|
|
|
fletcher posted:I've got my Jenkinsfile going now and building AMIs on every commit. Next step is to run the terraform apply at certain times of the day to actually deploy the new AMIs to a test environment. What's the right approach for doing that? I had done something kinda similar previously with the Copy Artifact Plugin. The AWS process is usually making a new launch configuration that specifies the new AMI and updating the autoscaling group to use the new launch config. So whatever terraform calls those is probably what you're looking for.
|
|
#
¿
Nov 11, 2017 02:48
|
|