Dev vs. production builds

suggest change

For backend servers it's common to need dev vs. production configurations where you e.g. point to a different database server etc.

// !build dev

package config

const (
	MONGODB_HOST = "mongodb://127.0.0.1:27017"
)

// !build prod

package config

const (
	MONGODB_HOST = "mongodb://mongo.myserver.com:27017"
)

We then build go build -tags dev for development build and go build -tags prod for production build.

Found a mistake? Have a question or improvement idea? Let me know.

Conditional compilation with build tags:

* Specifying multiple tags

* Ignoring files (excluding from compilation)

* Predefined build tags

* Using file name in place of a build tag

* Pitfalls

* Separate integration tests

* Optimized implementations for specific architectures

* Dev vs. production builds

Table Of Contents

0 Getting started

1 Basic types

2 Variables

3 Constants

4 Strings

5 Pointers

6 Arrays

7 Slices

8 Maps

9 Structs

10 Interfaces

11 Empty interface

12 if, switch, goto

13 for, while loops

14 range statement

15 Functions

16 Methods

17 Error handling

18 Defer

19 Panic and recover

20 Concurrency

21 Channels and select

22 Mutex

23 Packages

24 Files and I/O

25 Time and date

26 Command line arguments

27 Logging

28 Executing commands

29 Hex, base64 encoding

30 JSON

31 XML

32 CSV

33 YAML

34 SQL

35 HTTP Client

36 HTTP Server

37 Text and HTML templates

38 Reflection

39 Context

40 Package fmt

41 OS Signals

42 Testing

43 Calling C from GO with cgo

44 Profiling using go tool pprof

45 Cross compilation

46 Conditional compilation with build tags

47 Inlining functions

48 sync.Pool for better performance

49 gob

50 Plugin

51 HTTP server middleware

52 Protobuf in Go

53 Console I/O

54 Cryptography

55 Images (PNG, JPEG, BMP, TIFF, WEBP, VP8, GIF)

56 The Go Command

57 Testing code with CI services

58 Windows GUI programming

59 Contributors