|
'sup hg / C# / MVC / fullstack buddy. Thanks for starting this thread -- it is greatly needed.quote:I'm a C#/.NET/MVC/~full stack~ guy. Everything is windows this IIS that. We use bitbucket as our git repo host. What are my (GOOD) options to set this up? Which ones have which advantages? Is this a thing I can do in powershell or do I really need to get and configure something complicated? First, you've got the right idea -- end of the day this deployment process needs to be callable from a command line, perhaps with a few parameters to tell it where to shoot. I would develop the pointed part of the process there if for no other reason than it is alot easier to debug your local powershell environment then rely upon a build server doing fancy hoo-ha to do everything. Moreover, in the cases where fancy tools fail if you can deploy via command line you can always have a way out and deploy poo poo when the rest of the system is failing. One other angle is that there are some things you need to do in development and others you need to do in producction (or qa / staging / whatever you call it which is really production with stale data ). I'll start at the dev side. For achieving frictionless development -- the idea of building projects by spinning up of VMs and poo poo like that you need to start and stop with Vagrant. It makes that sane, rational, trackable and repeatable. Generally we don't use vagrant for .NET stuff as Microsoft has done a pretty amazing job of setting things up so you can fly off IIS express / Sql Express locally and get close enough to prod to not need to wait on VMs to spin up to work. But our stuff tends to be relatively uncomplicated and/or architected to make sure we can keep this dev story up while hiding complexity. YMMV. In terms of scripting things powershell is a good option to some extent. We managed to get pretty jiggy with MSBuild back when there werent better options. These days I'm starting to fall in love with fake for a variety of reasons. Or at least it is a good excuse to try F#. When you get to the QA / test part of this story this is where you are really going to want to get some tools in play. Personally, I love TeamCity and find it to be worth every cent of the rather cheap license. You can probably get to the same places with jenkins if you don't have a budget. Microsoft also has rolled has some TFS online stuff but I'm loath to depend on them for that part of my development cycle. Anyhow, the build server is really a pretty fancy job runner and reporting system that happens to be tuned to talk to source control and test suites. The real magic tends to happen on the build slaves -- this is where the builds actually execute. For instance, we run 4 -- 3 in various network segments and a mac build server for iOS stuff. How I'd approach something like you are taking about would be: 1) make sure I can build things and get things orchestrated to be ready to run tests from the command line. State is the bane of software development and this is no different -- the biggest challenge is dealing with teh DB. We use RoundHousE for our SQL/.NET stuff to provide a CLI to handle those tasks. I like it because it works the way I want -- that is to do things like mount a database backup and also to execute sql migration scripts in a defined order -- while not making presumptions about my code or my DB. Moreover, it is a command line executable we can ship with code so I can xcopy files, run stuff and it just works when systems fail me. Figuring out a way to schlep the data to the tests is a trick. If it isn't sensitive then having a http download is the least friction. Source control will usually melt with real databases, especially binary sql backups. Anyhow, figure out a way to get the data you need mounted near your tests. Or near enough to load in. Better yet figure out how to write tests without database state or tests which create their own database state. 2) Figure out what the deployment flow should be -- IE do you backup before you pull the trigger? What is the rollback plan? Etc, etc. FWIW our general plan is "rollback is rolling out a quick bugfix" as rollback gets real tricky real fast. Also FWIW we settled upon a basic flow for the .NET stuff of first building the binaries and other packages on the build machine then xcopying them into hot IIS directories. This has worked very, very will with minimal downtimes, etc. We have about zero session dependence which would get broken by this unless you are running out of proc sessions. 3) Configure the build server to execute your build based on whatever criteria you want -- we are pretty manual here, at least for the deployment ones. But you can base it on branches / tags / what have you depending on how your flow is. That is just a configuration option for the build server. This is also the place you would integrate the test suite here so it will stop the final "deploy this poo poo" step if it fails. Or not depending on what management needs. In terms of IT and management to some extent it depends on the people and mentality. I know part of our shop hates this poo poo -- they feel [kinda rightly] like I'm replacing them with robots. The other part loves it because who wants to run through 2 pages of deployment instructions when they could be off solving real problems. Presuming the management is reasonably forward thinking they are easy to sell -- just tell them google and amazon are doing continuious delivery so you should be too. So, alot of specific depend on your environment but the first step is to make your things automatable. Then it is a matter of picking tools to automate. Though getting deployments down to "run this script and wait for the smoke to clear" gets you 90% of the way there. The rest is just fancy reporting. Hope this helps, happy to dive into more details if needed. [edit: the first cut needed some wordsmithing] wwb fucked around with this message at 00:59 on Jan 22, 2015 |
#
¿
Jan 21, 2015 23:39
|
|
|
|
| # ¿ Apr 28, 2024 19:58 |
|
|
Speaking of iOS if anyone has unlocked whatever magic voodoo it takes to get apps successfully building for distribution on a headless setup using a build server please share.
|
|
#
¿
Jan 23, 2015 13:39
|
|
|
Yeah, we admitted defeat on the hardware front -- I've got a mac mini running in the CI rack now. It actually has been generally useful as a CI slave for our LAMP deployments too. The approach we were trying was to use a bash script to do the fundamental execution using the apple toolchain. We never could quite get it to actually use the keychain we wanted it to use, nor could we cheat and have it use the SSH user's keychain. Some of this probably has to do with limited seat time building stuff on macs but then again I got android building release / store ready signed artifacts inside of an hour so it can't be that tricky.
|
|
#
¿
Jan 23, 2015 17:24
|
|
|
Dust!!! posted:I'm the "automated Android and iOS builds" developer where I work. The actual process of building release artifacts can be very simple for both platforms. Getting to this point in iOS is much more difficult than it is with Android because of code signing. . . Thanks. I think shenzen might be the missing link I was looking for.
|
|
#
¿
Feb 3, 2015 14:07
|
|
|
beuges posted:I run a small consulting business, doing development for a bunch of different clients. I've been looking at setting up a CI/build server to get things a bit more organized. Most of our dev is C# - typically MVC for web, a mixture of WCF and Web API for services, and some windows services/console apps as well. However, we also do a reasonable amount of work for a couple of clients in C on the Raspberry Pi (we currently build everything using the CodeBlocks IDE on the pi itself, but do most of the dev on Windows under Visual Studio), and some embedded C dev on credit card terminals as well (NetBeans IDE with Cygwin+ARM cross compilers). There's also one java project using Eclipse and Maven and Spring and some other junk. Check out TeamCity if you want a product or Jenkins if you want free. I wouldn't get hung up on promoting binaries unless you've got really long test cycles.
|
|
#
¿
Mar 2, 2015 14:24
|
|
|
It isn't if you understand the pricing model. TeamCity is a freemium product. It is free at a certain level -- that is 3 build agents and 20 or so projects. Beyond that you need to pay but if you've got that much going on then it is pretty cheap compared to a lot of products -- like $2k or so a year.
|
|
#
¿
Jun 5, 2015 14:45
|
|
|
Zero seat time with go but I think you can set environment variables and such in teamcity. I would probably look at having a GOPATH setup right and smylinking in the source folder. If there is a good resource on the structure drop a link and I'll see if I can give some better advice.
|
|
#
¿
Sep 29, 2015 23:28
|
|
|
I just read http://hadihariri.com/2015/09/30/setting-up-go-on-intellij/ which gave me about 1000% more understanding of go setups than I had when I woke up this AM. Anyhow, a really straightforward way to do this would be to set TC to check out the project to a specified path on the agent that is within the gopath you setup on the agent. You will probably still need to set the gopath environment variable -- or set it up for the user who the build agent is running as -- but that should be the most straightforward way to do this though it won't scale horribly well.
|
|
#
¿
Sep 30, 2015 19:07
|
|
|
^^^ this. Build agents are really coordinators, with ssh you can execute on any box you want. Most of our linux deployment punches through windows build agents left over from the pure-bred .NET shop days. Now where vagrant and devops meet is provisioning -- you can usually setup the same provisioning scripts for both environments with a bit of configuration voodoo.
|
|
#
¿
Oct 21, 2015 18:25
|
|
|
My main concern is if they maintain it as well as they maintained CC.Net -- which is to say not at all.
|
|
#
¿
Nov 16, 2015 21:17
|
|
|
TeamCity or Jenkins should be able to handle this pretty well. On the bitbucket side you just need something that speaks hg or git. On the orchestration something you need somethign that can run your scripts in the prescribed manner. Both of those can handle that with aplomb. TeamCity is a bit nicer and better with .NET out of the box but both will get you there.
|
|
#
¿
Nov 17, 2015 18:49
|
|
|
^^^ this. This is on by default now but there are 5+ years of laptops with this disabled by default. Of course, changing BIOS settings in an environment like that might require filing a 42 page form in triplicate and 3 dozen meetings. As for the task at hand, it is a great thing when you get done. The big trick is getting vagrant provisioning to do all this dirty work, getting to 100% automated is tricky. Another trick is how to schlep around the database backups if that is important. We are using subrepos for that and it is working OK except for a few sites that have gigabytes of stuff. For your AD problem a few notes. First is that, in my experience, any outgoing network activity if you are using a typical vagrant / virtualbox setup is going to be slow as bjezus, especially on Windows. Second, Rails tends to talk to LDAP not AD per se so the approach I would start with is to find some LDAP server you could setup in the dev environment to handle those calls and take the remote AD out of the loop.
|
|
#
¿
Dec 18, 2015 18:13
|
|
|
I think the key difference between sysadmins and devops folks is the approach to the problem. Sysadmins fix things so they aren't broke. Devops types recast the system so that problem will never happen again in a way where you've got revision history and rollback baked in. The interview questions I'd start with are: # What is your line between "this is a manual process and 'we must script this'" -- devops should answer "what kind of crack are you smoking to have a manual process; script all the things." # What is your favorite VCS? -- devops should have an educated answer here. # Why are orchestration systems better than shell scripts? -- devops should have an educated answer here too, traditional sysadmins who get orchestration systems will note something like "yeah, fewer lines of bash"
|
|
#
¿
Jan 14, 2016 01:22
|
|
|
For chef I'm still somewhat in favor of manual dependency resolution if for no other reason than it helps you keep you mindful as to what you are running. Some of those major cookbooks are way, way bloated and have a bunch of odd dependencies that can bite you in the rear end down the road. I'll also note that, IMHO, Chef/Ansible really do different things than one should be doing w/ TeamCity and Octopus. In our shop we divide responsibility for spinning up machines (chef) and deploying apps (TeamCity). YMMV.
|
|
#
¿
Feb 11, 2016 16:35
|
|
|
|
| # ¿ Apr 28, 2024 19:58 |
|
|
SSH from windows is pretty easy these days. Microsoft is working on an official solution, but for now you can just go download portable git and add it's bin folder to your path -- that will get you cross-compiled ports of most of the *nix toolchain including ssh.exe.
|
|
#
¿
Mar 25, 2016 20:58
|
|